Subject: [eap] Re: questions on AAA key management draft

From: Russ Housley <[email-masked]>
Date: Sun, 06 Nov 2005 18:28:32 -0500

Madjid:

>I just spent a bit of time going through the AAA key management draft
>(V00) and have the following comments.
>
>First of all I appreciate Bernard and Russ providing guidance for the
>community and am wondering if there is a plan for sequels? And I don't
>know which WG this draft was targeted for? AAA WG maybe? And I apologize
>if I don't have the history on this draft. I am drawing parallels
>between this draft and EAP keying drafts based on the following (may
>that is not the intention).

The goal is to publish a BCP RFC.  Our hope is to submit the document 
to the IESG before the end of the year.  To that end, I hope to 
publish -01 by the end of this week.

>The draft provides a lot of history for why EAP came about, and talks
>about combination of EAP and RADIUS, as well as EAP methods and post EAP
>handshakes, it does sort of confirm the impression that it wants to talk
>about key management using EAP and AAA protocols. However, I think the
>following would lead to improvement
>
>1)the draft could be more clear when it deals with a AAA process and
>when it deals with an EAP process
>
>1a)Initially picking up the draft with excitement I thought the draft is
>talking about management of THE "AAA-key" produced as a result of EAP
>process (sort of what EAP key management draft is defining). Ironically
>that is the first thing that is sort of confusing. So "AAA assisted key
>management" might be a good alternative!?

How about: Guidance for AAA Key Management

>1b) distinction between EAP server and AAA server. Distinction between
>what is done by AAA protocol and what is done by EAP. For instance:
>
>1c) It talks about key caching but it would be nice if it included where
>keys should or should not be cached (AAA server, AAA client, EAP
>authenticator, EAP server etc.) Some of this is covered in EAP RFCs or
>the new keying drafts, but others are not, simply because RADIUS RFCs
>where written before EAP ones. It is becoming harder and harder to find
>a one-stop shop for advice or spec to find the rules or point people to
>in debates. Even then a lot of hair splitting between various documents
>is required.

I do not think that the party performing the caching is the important part.

A fresh cryptographic key is one that is generated specifically for the
intended use.  In this situation, a post-EAP handshake is used to
establish session keys.  Thus, the AAA protocol and EAP method MUST
ensure that the keying material supplied as an input to session key
derivation is fresh, and the post-EAP handshake MUST generate a separate
session key for each session, even if the keying material provided by EAP
is cached.  Further, the session keys MUST NOT be dependent on one
another.  That is, disclosure of one session key does not aid the
attacker in discovering any other session keys.

>1d) "replay detection mechanism: AAA key mgmt protocol exchanges MUST be
>replay protected" Is the draft proposing ways to fix AAA (RADIUS or
>Diameter) messaging? EAP messaging? Or only attributes that deal with
>key management, I would think the latter.

The document is not proposing any fixes.  It is placing requirements 
on standards-track solutions.

>Other comments:
>
>2) Not initially very clear what is meant by "session keys" in "strong,
>fresh requirement", I am assuming we mean keys that are produced as part
>of session association protocol (SAP), since the subsection later talks
>about post-EAP handshakes. However, one paragraph does talk about keys
>derived by EAP methods, so not sure if MSK, EMSK, AAA key needs to be
>fresh, or Tasks or all. Given that the draft recognizes the definition
>of SAP, using both SAP and post-EAP handshake can be pretty confusing.

I do not have a better term to use here.  It does not look like you do either.

>3) More guidance on key scope is appreciated. For instance the scope of
>key is defined by using the "least privilege" principle. From the point
>of key derivation (who has the master key and the material to derive
>further keys), I think this is clear to some extent, but since this
>document advertises as providing guidance for AAA-based key management,
>I think guidance on how it is possible (or not) for the AAA
>infrastructure to control the key scope is useful. I have combing
>through a lot of EAP keying material in the past year, I still have not
>understood how much control the AAA server can exert on the key scope
>and hierarchy (who can create what key from what, is AAA server aware of
>SAP? Should it be?)

This requires correct operation of all parties that hold the keying 
material needed to compute any subtree in the key hierarchy.  I'm not 
sure that there is any useful guidance.

>4) Key material confidentiality: Is nonce not considered as keying
>material. If SAP (or post-EAP handshake) uses nonces, I did not think
>they did not need to stay confidential?

No, nonces are not keying material.

>My final but not least important comment is that a lot of SDOs are
>starting to use AAA key management mechanisms (using your terminology)
>to provide security for mobile environments and in the absence of clear
>guidance are creating a number of procedures that this very draft is
>stating to want to avoid. Would it not really be helpful if this draft
>provided more guidance for this densely populated category of people?
>i.e. guidance on how to do use AAA-based key management mechanisms to
>support handovers?
>
>For instance it is not clear from the draft and its
>  "prevention of Domino effect/ keying material confidentiality"
>requirements whether
>  context transfer of keying material from one authenticator to the next
>for support of fast mobility ruled out?

My going position is that this should not be allowed.  It would mean 
that the compromise of one authenticator has serious ramifications on 
other authenticators.  I am willing to listen to arguments to the 
contrary, but it will take a compelling argument to change my mind.

>Would we violate principle of least privilege even though we only move
>MSK between authenticator? Or the post EAP keys between BSs (consider
>802.16 model).

Take a look at the work going on in 802.11r.

Russ

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

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 8 Nov 2005 20:42:25 +0200

Hi Russ,

> contrary, but it will take a compelling argument to change my mind.

In PANA WG, we have a mobility optimization that relies on an anchor NAS
providing a session key to another NAS. Please see:

http://www.ietf.org/internet-drafts/draft-ietf-pana-mobopts-01.txt

Let me summarize it here using general terms:

NAS1 has already executed EAP with the client, and holds AAA-Key1. When
the client moves to NAS2, instead of running EAP again and generating a
new AAA-Key, this solution relies on NAS1 generating an
AAA-Key-int(erim) as follows:

AAA-Key-int = PRF(AAA-Key, NAS2-ID | Client-Session-ID)

NAS1 passes the AAA-Key-int to NAS2. NAS2 generates a new AAA-Key-new
as:

AAA-Key-new = PRF(AAA-Key-int, NAS2_nonce | client_nonce)

AAA-Key-new is used by the client and NAS2 until a new round of EAP
authentication is executed.

As we wrote in the security considerations section, compromise of NAS1
along with interception of nonces on the new link lead to compromise of
NAS2. But, compromise of NAS2 does not lead to compromise of NAS1. We
also suggested that for deployments that want to reduce the potential
threat should subsequently force the client to perform a new EAP
authentication with the NAS2.

We'd like to hear your thoughts on this. 

Given that this is an optional feature with a documented risk/warning
and a suggested remedy, do you still see issues with this?

Regards,

Alper