Subject: [AAA-WG]: Another shot at Issue 414: Key AVPs

From: <[email-masked]>
Date: Mon, 9 Feb 2004 14:37:46 +0200

Hi,

The one major still open in Diameter EAP application is the
AVP(s) to be used for keys. There are several complications:
while some link layers (such as 802.11i) are happy with a single
key, some (e.g. MPPE) need two. Also, we would like to be
compatible with the de facto RADIUS practise (MS-MPPE-*
attributes), so translation should work "well enough" in 
both directions.

The current sketch in -03 draft does not really support having
more than one separate key. I listed some possible alternatives 
while working on -02 version:

http://www.drizzle.com/~aboba/AAA/issues5.html#Issue%20414

ÍMHO, alternative #3 seems the best of those, but it requires 
that translation agents translating from RADIUS Access-Accept 
to Diameter-EAP-Answer can figure out the correct key type...

I had a chat with Jari a while ago, and we came up with a simple
(if not very elegant) alternative... so, I'd like to ask your
comments about the following:

4.1.3 NAS-Session-Key AVP

   The NAS-Session-Key AVP (AVP Code TBD) is of type OctetString.  
   It is used by the Diameter server to deliver keying material 
   to be used between the client and the NAS.

   More than one NAS-Session-Key AVP MAY be sent, and their order is
   significant. The interpretation depends on what security
   mechanisms are going to be used between the client and the NAS:

   o  For IEEE 802.11i, only a single NAS-Session-Key AVP is used:
      it contains the Pairwise Master Key (PMK).

   o  For MPPE, two NAS-Session-Key AVPs are used: the first contains
      the uplink (Recv) key, and the second contains the downlink 
      (Send) key.

6.1 RADIUS Request forwarded as Diameter Request

   ...
   o  Diameter NAS-Session-Key AVPs can be translated to the
      vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key
      attributes [RFC2548]. If more than one NAS-Session-Key AVP is
      present, the first is translated to MS-MPPE-Recv-Key and the
      second to MS-MPPE-Send-Key. The encryption of this attribute is
      described in [RFC2548].

6.2 Diameter Request forwarded as RADIUS Request

   ...
   o  If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or
      MS-MPPE-Send-Key attributes [RFC2548], they can be translated to
      Diameter NAS-Session-Key AVPs. If both attributes are present,
      MS-MPPE-Recv-Key corresponds to the first NAS-Session-Key AVP
      and MS-MPPE-Send-Key to the second. The attribute has to be
      decrypted before conversion, and only the Key sub-field is
      stored to the NAS-Session-Key AVP (i.e., Salt, Key-Length and
      Padding are discarded after translation).

Another possibility would be to use alternative #3, but add 
an "UNDEFINED" EAP-Key-Type value; this could be used by 
translation agents when they can't figure out the key type
(this would be somewhat similar to what is proposed above,
except that the individual AVPs would be inside one grouped 
AVP instead of being at the "top level").

Comments welcome...

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Feb 2004 06:00:47 -0800 (PST)

I think this proposal requires that the NAS send the NAS-Port-Type AVP.
Otherwise, how will the AAA server know what which type of key to send?

Also, how does the AAA server know what ciphersuite is going to be
negotiated?  Some ciphersuites might need both keys, some only one.  But
ciphersuite negotiation can occur *after* the keys are sent.

So I'm not clear how the AAA server can figure out which key(s) to send.
And if it guesses wrong, the session cannot go forward.