eap Mailing List: [eap]: questions on AAA key management draft

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi,

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 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!?

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.

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.


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.

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?)

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? 

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?
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).


Thanks,

Madjid Nakhjiri