Subject: [AAA-WG]: Issue 188

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Oct 2001 07:24:56 -0700

The issue says:

"The NAS-Key-Binding AVP specifies the purpose of the
session key. The AVP MUST be included if the NAS-Session-Key
AVP is included. The key binding specifies which ciphersuite
will be used between the NAS and the user. The problem is that
the ciphersuite may not have been selected yet.

In PPP, ECP is used to negotiate the ciphersuite and it occurs
between the user and the NAS after authentication.
In IEEE 802.11, the ciphesuite negotiation may as well
occur after authentication."

I think that this is a red herring: it doesn't matter if the ciphersuite is
negotiated _after_ authentication, because the Diameter server is _telling_
the NAS or AP which ciphersuite to choose.

"In addition, the NAS-Key-Binding AVP makes AAA servers
dependent on and aware of different ciphersuites, so they
need to be updated if a new ciphersuite is specified."

This is a more reasonable concern, but OTOH 1) the frequency of the adoption
of new ciphersuites is probably going to be fairly low and 2) the task of
updating the Diameter servers w/a new ciphersuite type seems to pale beside
that of updating the access devices to support the new ciphersuite.

"Even if the ciphersuite hasn't been selected, the AAA server
can still transport keying material to the NAS in the
NAS-Session-Key AVP. For example, it can include large
session keys which the NAS can truncate as necessary for use
with a given ciphersuite."

Isn't there more to it than just transporting & truncating keying material,
though?  For instance, DES, RC4 and other algorithms have so-called "weak"
keys...