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

From: <[email-masked]>
Date: Mon, 9 Feb 2004 16:50:36 +0200

Bernard Aboba wrote:

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

Hmm, yes... if derivation of AAA-Key from MSK depends on 
the ciphersuite (or at least on link-layer type if not exact
ciphersuite), then the AAA server has to know it. This is 
the case if e.g. AAA-Key has some internal structure 
with variable-length parts, like MPPE Send/Recv keys.
So actually we have this problem already in RADIUS:
the AAA server could send different key attributes depending 
on whether e.g. EAP-TLS is used for MPPE or 802.11i.

It seems that current AAA servers don't care about this, and
always send 64 bytes of keying material (?). 802.11i will use 
only half of that (first 32 bytes or Recv key), and if I 
understood RFC3079 right (?), MPPE will also use half, but 
it's bytes 0..15 and 32..47 (first 16 bytes of Recv/Send keys 
each).

If we can assume that all AAA servers do this, then we could
live with the single 64-byte AVP that draft -03 has. (When
translating from RADIUS to Diameter, just concatenate the
32-byte Recv/Send keys, and split the key when translating back.)

However, it seems that when using MPPE the AAA server could
actually send only the first 16 bytes of MS-MPPE-Recv/Send keys;
and then translation gets difficult... is this a concern, or
could we assume that AAA-Key is always exactly 64 octets?
(or does not have variable-length internal structure)

BR,
Pasi