Subject: Re: [eap] Re: Rewrite of Section 2 of the EAP Key Management Framework

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Oct 2005 18:03:13 +0300

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 19 Oct 2005 14:35:36 -0700

>> Hi Bernard,
>> 
>> I think in general this looks pretty good.  I have some comments and
>> questions: 
>> 
>> Section 2.3
>> 
>> - In paragraph 4 it states
>> 
>> "In either case, it can be assumed that the parties do not utilize
>> the link to exchange data traffic unless their authentication
>> requirements have been met." 
>> 
>> Is there a reason why it is useful to assume this?  I'm not sure that
>> it needs to be true (although I agree that it often is).
>> 
>> 
> I think it is a simplifying assumption that at least for me
> clarifies what the situation is when parties utilize the link
> for data traffic. But let me turn this around:
> can you cite an example where it would be useful to NOT assume this?
> 
[Joe] When there is no ciphering there are cases where some traffic
maybe allowed on the link before authentication is complete.  This could
also be possible in the ciphering case that the peer and authenticator
could allow certain types of traffic on the link, but I don't know any
off hand.  The text is probably OK as it is.  
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 20 Oct 2005 12:15:51 -0700

Hi Bernard,

Comments/questions below

> 
> My current proposal is to state that the EMSK is passed down
> to the EAP peer/authenticator layer and EAP layer, but is
> never passed down to the lower layer, although keys
> calculated from the EMSK can be passed down to the lower
> layer if requested by the lower layer, as long as the EMSK itself is
> not exposed. 
> 
>> "Instead of using the EMSK directly keys should be derived for
>> application specific usage.  This usage and specification is beyond
>> the scope of the current document."
> 
> I think that some language specifying that the lower layer
> never receives the EMSK, or quantities from which the EMSK
> can be derived should do the job.

[Joe] My concern with the above is that you may not want all of the
authenticator to have access to the EMSK.  You would probably want it to
remain with the part of the authenticator that hosts the EAP server.