eap Mailing List: RE: draft on authenticated service identities

[Alper Yegin (alper.yegin]

Hello Jari and Pasi,

Thanks for chasing this issue down and putting this draft together.

I agree something needs to be done regarding binding the service to the
authentication, and considering several service-related attributes is a
necessity.

The attribute verification can be performed in different ways. I see
your draft proposes it being done both on the peer and the
authentication server. This is somewhat redundant, unless I'm missing
something. Either peer or the auth. server could perform this
verification and fail the AAA in case of discrepancy (modulo the
policy). I guess giving the authority to perform this check and fail the
session to each end give additional flexibility, but at the price of
possibly increased complexity.

Also, performing the exchange of the attributes in-band with the EAP
authentication methods creates dependency on a specific feature with the
methods. Have you considered performing this outside EAP? For example,
via EAP lower layers.

The framework requires extensions to the AAA backend protocols. This is
briefly mentioned in the Security Considerations section, but eventually
I think it deserves some elaboration.

   3.2.1 Service Type Parameter
   ...

      0  PPP
      1  IEEE 802.11
      2  PANA
      3  IKEv2

I think this service type space, as defined in the draft, is not as
homogeneous. PPP, PANA, and IKEv2 (EAP lower layers) can be used on IEEE
802.11 (a link-layer type).

To me, there are the following views:

a- access type: remote (VPN-based) vs. local
b- EAP lower layer: PPP, IEEE 802.1X, PANA, IKEv2
c- Access technology: IEEE 802.11, DSL, GPRS, IP-in-IP tunnels (VPN),
etc.

Maybe we can see the service type from the view of (b).

Regards,

Alper
 







> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
> Behalf
Of
> Jari Arkko
> Sent: Friday, April 02, 2004 4:57 AM
> To: eap [at] frascone.com
> Cc: Pasi Eronen
> Subject: [eap] draft on authenticated service identities
> 
> 
> Pasi and I have written a draft on the authentication
> of service identities (= service parameters claimed
> by access servers) in EAP. Essentially, the draft
> is an extension of EAP-TLS, EAP-SIM, EAP-AKA, and PEAPv2
> for transporting and authenticating parameters related
> to the offered service. This makes it possible to ensure,
> for instance, that everyone agrees about the claimed SSID
> or that a compromised access point can not present itself
> as an IKEv2 gateway.
> 
> Here's the abstract:
> 
>     A common arrangement in network access is the separation of the
>     actual network access device (such as a wireless LAN access point)
>     from the authentication servers. In the Extensible Authentication
>     Protocol (EAP) framework, different authentication methods can
>     provide varying security properties. If the EAP methods support
>     authentication of service identities, it becomes possible for the
>     clients to verify not only that the access device is trusted, but
>     also that the parameters advertised by the access device are
correct.
>     This document specifies a backward compatible extension to popular
>     EAP methods for supporting such service identity authentication. A
>     common parameter name space is created in order to ensure that the
>     same parameters can be communicated independent of the choice of
the
>     authentication method.
> 
> The draft has been submitted, but before it appears
> in the official directories, you can access it from
> the following URLs:
> 
>
http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-
> auth-00.txt
>
http://www.arkko.com/publications/eap/draft-arkko-eap-service-identity-
> auth-00.html
> 
> Comments are appreciated.
> 
> --Jari
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap