eap Mailing List: RE: EAP-Keying draft issues

[Walker, Jesse (jesse.walker]

Russ,

-- snip --

>>This reasoning suggests that a better scheme might be use the TEKs as
>>end-to-end key wrapping keys, instead of the MSK and EMSK as key
>>derivation keys (or else perhaps use the MSK or EMSK as key wrapping
>>keys, since TEKs live only during the EAP conversation).
>
>I am not sure.  I like the fact that the TEK has only one purpose in
the 
>current architecture.  This is also a conservative design principle.  I
am 
>not sure that NIST would want this one sacrificed for the one discussed

>above.  It sounds like open dialogue is needed.
[Walker, Jesse] I share your point about 1 use per key. My point was not
to suggest using keys for multiple purposes, although I can see how that
interpretation is possible. My point was to raise the question of
whether the current architecture is where we want to end up. My reasons
for asking the question at this time were (a) the keying draft appears
to be in last call and (b) there appeared to me to be a conflict between
requirements that may be forthcoming from NIST and the performance
requirements for new applications like fast AP-to-AP transition.

-- snip --

>>People have pointed out before that EAP is a two-party protocol, and
>>that we can't change the EAP model, and I am sure they will again.
>>However, the reality is we don't have to change EAP authentication one
>>whit to address this problem, because it has nothing to do with
>>authentication; it is about what to do with the results of
>>authentication and the resulting authorization decision. All we need
is
>>one three-party scheme to deliver keys (properly bound to the
>>authenticated identities of the NAS and Peer) to the NAS and to the
>>Peer; we don't want some indeterminate number or 15 or 5 or even 2;
just
>>1 proper key delivery that will allow applications to meet the SP
800-56
>>requirements. Even if EAP is itself two-party, the key distribution
>>scheme can very well be three-party. And there are ready-made
algorithms
>>we can pick up and use (e.g., Needham-Schroeder, Otway-Rees,
>>Bellare-Rogaway) if only we want to.
>
>It is not clear to me the exact requirements.  Jesse, I ask you to 
>coordinate with other people in IEEE 802.11 to state them clearly.  It 
>would be ideal if they come to the IETF in a liaison letter.
[Walker, Jesse] This is a fair request. I will work toward this end.