Subject: FW: [eap] Re: EAP key binding discussion

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 27 Apr 2005 14:59:45 -0500

Sorry for the late response to this. I have written something up. It is more a problem statement than a solution proposal. Basically because I was not sure whether sending the AAA key to some place other than an authenticator is against EAP key management principals.
I am sending this in the following email.

Regards,

Madjid

>Instead both the peer and EAP/ AAA server calculate a
>AAA-BS key that is bound to that base station. The EAP server only pushes
>the AAA-BS key to that BS (NAS). The AAA key to AAA-BS key is
>straightforward if you know the BS ID, peer ID and other things, as long
>as you know AAA key, of course, so the peer and AAA server both can do
>it. The handshakes happen based AAA-BS rather than AAA-key. But now, the
>BSs cannot derive the session keys for other BSs.

You are describing something which I don't believe is included in any of
the existing proposals.  If this is something that you're interested in
pursuing, the best way to go about it is to write a complete proposal for
how it would work, and then analyze it to see if conforms to the security
criteria in RFC 4017.  This would make it possible for the proposal to be
included in the EAP Key Management Extensions draft.

However, please understand that this is not something that is likely to be
completed in the 802.16e timeframe.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Apr 2005 21:49:48 -0700 (PDT)

> Sorry for the late response to this. I have written something up. It is
> more a problem statement than a solution proposal. Basically because I
> was not sure whether sending the AAA key to some place other than an
> authenticator is against EAP key management principals.

The Housley Criteria are described in RFC 4017 as well as the EAP Key
Management framework.

In particular, I would pay attention to the "Confidentiality" condition
(which prohibits disclosure of keys to parties outside the peer, server
and authenticator), the "mutual authentication" condition which requires
mutual authentication between all parties, and the "domino effect"
condition which prevents compromise of one party from affecting other
parties.