Subject: [eap] questions/comments on draft-walker-aaa-key-distribution-00.txt

From: [email-masked] (Glen Zorn)
Date: Fri, 03 May 2002 15:19:55 -0700

Editorial nit: the first page headers seem misaligned (in my copy).

Section 2, paragraph 2 says "The purpose of NASREQ key distribution is to 
securely establish a  session key between the NAS and the NAS 
client."  While this true in a general way, a more precise characterization 
might be that the purpose is to securely _inform_ the NAS of session keys 
which have been derived without its knowledge, possibly as a side-effect of 
a successful EAP authentication.

Section 2, paragraph 3 seems to come to some reasonable conclusions, but 
for the wrong reasons.  For example, it says: "[NASREQ] allows the AAA 
server to distribute a key to the NAS client using EAP, but does not 
specify how this is accomplished."  Actually, this is a mistake in the 
NASREQ draft: instead of saying (in Section 2.1.2) "The keys MAY be 
distributed to the user as part of an EAP authentication exchange." it 
should actually say nothing at all, or maybe something like "The means by 
which the user obtains the keys is outside the scope of this document.", 
because it is.

Paragraph 3 continues: "EAP fails to specify mechanisms.  As a result, all 
mechanisms assume that the AAA server and the NAS client already share a 
key that may be used directly to protect the link between the NAS and the 
NAS client, and so it is unnecessary to distribute any key to the NAS 
client.  Since no specified instances of EAP key distribution to the NAS 
client exist, the implicit assumption has to be that such mechanisms are 
unimportant...".  Actually, the is another assumption possible, though not 
particularly implicit: that EAP types which offer key derivation will 
provide it in a fashion that makes distribution to the NAS client 
unnecessary.  In fact, that's just what has happened: virtually all EAP 
types that provide for key derivation do so in a such a way that only the 
EAP server (not identical to the AAA server as is mistakenly implied in 
your draft) and the EAP client can have knowledge of the keys.

Continuing: "and will not be deployed as part of the AAA 
architecture.  That is, the lack of any defined EAP key distribution 
mechanism, and the further lack of any work on such a mechanism, implies 
that the AAA Working Group implicitly assumes it is only necessary to 
distribute the key to the NAS."   A very good assumption.

The biggest problem with this draft, however, is the apparent 
misunderstanding of the parties involved and the interactions between them, 
a mistake I alluded to above: much of the remainder of the draft builds 
upon the supposed three-party nature of the conversations when actually 
there are four logical parties involved, one of which (the AAA server) is 
nonexistent as far as the NAS client is concerned.  The NAS client never 
communicates with the AAA server, the NAS may or may not communicate 
directly with the EAP server (probably not, if a AAA server is involved).

Having said all this, however, there is a lot of good thought in the draft, 
though it may be more pertinent to the design of special-purpose 802.11 EAP 
types than to the re-design of AAA key distribution.