eap Mailing List: Re: questions on AAA key management draft

[Russ Housley (housley]

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