eap Mailing List: Re: draft on authenticated service identities

[Florent Bersani (florent.bersani]

Four very quick comments:

1) Many thanks for writing this draft! Indeed, while designing an EAP 
method or reviewing the existing ones, I formed the strong belief that 
much work could be saved (and better quality obtained) if EAP methods 
had a common pool from which they could pick up "standard" functions - 
such as channel binding - and focus on their specifics - such as the 
cryptographic parts. This belief echoes what Joe once proposed 
(EAP-TLV). I'll thus simply include a corresponding TLV and a reference 
to your draft on authenticated service identities in EAP-PSK to 
implement channel binding :-)

2) I agree that more discussion is needed regarding the parameters. For 
instance, I object with having WPA and 802.11i gathered to a single 
parameter value in section 3.3.4 page 8. it might prove important to 
differentiate between TKIP only and CCMP in the near future. In general 
more granularity could be provided for this section (not only WPA vs 
802.11i but perhaps also the unicast, group and AKM Ciphersuites). I'll 
try and provide a proposition for more detailed parameters - maybe input 
from IEEE 802.11i members could help?

3) Could and should the same work be done with error messages?

4) Your draft seems to collide with EAP media independence (at least 
from a wording point of view). Please see Bernard's mail below.

Cheers,

Florent

------- Original Message --------
Subject:     [eap] Issue 235: (Key Framework) Rewrite of Section 1
Date:     Sat, 3 Apr 2004 15:45:13 -0800 (PST)
From:     Bernard Aboba <aboba [at] internaut.com>
To:     eap [at] frascone.com

1.4.1.  Media Independence

  One of the goals of EAP is to allow EAP methods to function on any
  lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
  For example, as described in [RFC3748], EAP authentication can be run
  over PPP [RFC1661],  IEEE 802 wired networks [IEEE8021X], and IEEE
  802.11 wireless LANs [IEEE80211i].

  In order to maintain media independence, it is necessary for EAP to
  avoid inclusion of media-specific elements.  For example, EAP methods
  cannot be assumed to have knowledge of the lower layer over which
  they are transproted, and cannot utilize identifiers associated with
  a particular usage environment (e.g. MAC addresses).



Jari Arkko wrote:

> 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