eap Mailing List: Re: Re: Rewrite of Section 2 of the EAP Key Management Framework

[Jari Arkko (jari.arkko]

Looks very good. One issue below (and I'm still working
on the discussion you and Joe have had):

> 2.7.  Lower Layer Naming
>
>   Within the lower layer, the EAP peer and authenticator typically
>   utilize lower layer names to identify each other and define the scope
>   of cached keying material.  However EAP methods treat lower layer
>   peer and authenticator identities as opaque blobs and do not
>   interpret them.  For example, EAP peers cannot compare the lower
>   layer authenticator identifier with the Server-ID provided by the EAP
>   method, since these two identifiers will not be the same where pass-
>   through authentication is implemented.
>
>   For the purpose of identifying the authenticator to the peer, it is
>   RECOMMENDED that the NAS-Identifier attribute be provided by the
>   authenticator to the peer, and that if AAA is enabled, that the
>   authenticator/AAA client include the NAS-Identifer attribute within
>  
Re: providing NAS-Identifier to the peer. Maybe. But are
we sure this is really the identifier we want to use? RFC 2865
rules on NAS-Identifiers are sufficiently imprecise that NAS-Identifier
usage practises probably vary. But is there a real reason why
we must provide a recommendation is this space? I understand
the need to quantify scope of caching, but presumably this could
also be achieved in other ways.

Re: including NAS-Identifier in Access-Request. This seems
to be a weaker statement than what RFC 2865 already says:

[Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
NAS-Identifier (or both).

Or at least a different statement.

>   the Access-Request sent to the AAA server.  In order to ensure
>   against forgery, it is RECOMMENDED that the peer and authenticator
>   securely verify the authenticator identity, such as via the Secure
>   Association Protocol.
>  
--Jari