Subject: RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

From: Bernard Aboba <[email-masked]>
Date: Fri, 17 Nov 2006 10:10:23 -0800 (PST)

>Can you please provide a pointer?

Authenticator and peer identication issues are discussed in Section 
2.2.1 of draft-ietf-eap-keying-15.txt

>I'm wondering why we open the door for children keys living longer than the
>parent key.

There is a distinction between maximum and actual lifetime which is 
discussed in Sections 3.3, 3.4 and 3.5 in the EAP key management framework 
document.  Since the topic is fairly involved, I'm not sure this issue 
deserves much if any discussion in the AAA key management guidelines.  A 
short summary is that since EAP does not support re-authentication without 
re-key, if the root keying material changes (MSK, EMSK), so do the child keys 
(TSKs).  On the other hand, there is no requirement for authenticators 
to cache EAP keying material once TSKs are derived, and so TSKs 
(children) can continue to exist even after the parent (e.g. MSK) has 
been deleted. 

So child keys often do persist longer than the parent key, and there is 
no issue with this.  However, the maximum lifetime of the child keys 
cannot be longer than the maximum lifetime of the parent. 

>I understand. What is the affect of "SHOULD but not a requirement"? Is this
>like a "SHOULD-"? I mean, what do we lose if we drop the "but such a
>protection is not a requirement"?

I think what is meant here is that this is not mandatory (e.g. it's not a 
REQUIREMENT in RFC 4017). 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 17 Nov 2006 22:29:20 +0200

> 2.2.1 of draft-ietf-eap-keying-15.txt

According to my reading, we rely on this piece of text:

   The following steps enable lower layer identities to be securely
   verified by all parties:

   ...

   [g]  Communicating the lower layer identities between the peer and
     authenticator within phase 0.  This allows the peer and
     authenticator to determine the key scope if a key cache is
     utilized.

Through the exchange of such identifiers one can bind the MSK to the
identity of the authenticator. But.... this has issues, imho. RFC 3748 does
not mandate such a feature on the EAP lower layers. Not sure if any supports
such a thing. Rather than relying on another part of the architecture (phase
0 -- discovery), it's more appropriate to expect EAP to deal with this
identifier exchange (since it is the one who generates the associated MSK),
but it is too late for that now. 

All I'm trying to say is, EAP (RFC 3748) does not appear to support this
particular rule from draft-housley-aaa-key-mgmt. Just an observation.

> cannot be longer than the maximum lifetime of the parent.

This explains it very well. Thank you.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 17 Nov 2006 14:14:40 -0800 (PST)

> not mandate such a feature on the EAP lower layers. 

RFC 3748 doesn't talk about this because it isn't an EAP issue -- EAP 
methods treat the authenticator identity as an opaque blob (e.g. channel 
bindings). 

> Not sure if any supports such a thing. 

IKEv2 and IEEE 802.11r both support binding of the authenticator identity 
to the transient session keys.   IEEE 802.11i only supported binding of a 
port identity (MAC address).  

> Rather than relying on another part of the architecture (phase 0 -- 
> discovery)

>From a security point of view, there is no reliance on phase 0 -- the 
binding needs to be handled securely in a post-EAP handshake. 

> particular rule from draft-housley-aaa-key-mgmt. Just an observation.

It is a correct observation because the rule doesn't apply to EAP.  It 
applies to the lower layers. 

> This explains it very well. Thank you.

Is there an issue with the explanation in the document?

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 20 Nov 2006 00:12:54 +0200

> methods treat the authenticator identity as an opaque blob (e.g. channel

MSK is exported by the EAP method. So, I'd think the EAP method shall
provide the authenticator identity.

> port identity (MAC address).

I'm talking about MSK, not TSK. By the time EAP authentication is completed
successfully, there is an MSK but the EAP peer does not know the "identifier
of the parties to whom the session key is available."

> Is there an issue with the explanation in the document?

The I-D currently does not have any text describing this. So, it'd be useful
to include one. Russ had agreed with me, but I had a question about the
normative language. Your above text clarifies it all. Thanks.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Nov 2006 14:49:11 -0800 (PST)

> provide the authenticator identity.

EAP methods (optionally) export the Peer-Id and Server-Id.  They don't 
export the authenticator identity, since the authenticator is not a party 
in the EAP method conversation; it only acts as a forwarder.  

> of the parties to whom the session key is available."

At the completion of the EAP method conversation, the MSK/EMSK is provided 
to two parties,  the peer (identified by the Peer-Id) and the server (identified 
by the Server-Id).  

The lower layer then needs to bind the exported keying material to the 
lower layer identities of the peer and authenticator.  

For example, within IKEv2, the peer and authenticator identities are 
defined by the initiator and responder ID payloads.  In IEEE 802.11r 
they are defined by the peer MAC address and the R1KH-ID; this implies 
that on an authenticator, the key scope includes multiple ports, but on 
the peer it only includes the port over which the EAP conversation ran. 

> normative language. Your above text clarifies it all. Thanks.

Ideally this should be clarified in the document itself, not just in an 
email on the IETF list :)

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 20 Nov 2006 01:55:11 +0200

> to two parties,  the peer (identified by the Peer-Id) and the server

And to the authenticator (via AAA protocols). That's the issue I'm trying to
highlight. The third legitimate owner of the key is not identifiable by the
time the key is made available to all the parties. I don't see a definition
of "Authenticator-Id".

> email on the IETF list :)

Yes please :-)

Alper