Subject: [eap] Recommended resolution of Issue 32: Accept

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 11:57:09 -0800 (PST)

Issue 32: Keying confirmation
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 9.8
Rationale/Explanation of issue:

Section 9.8 continues on page 24 at the end of its paragraph 4:

This means that it is not possible for the Peer to validate
the identity of the Authenticator.

Actually, this is not necessarily true, either. Many reasonable keying
schemes require a key confirmation handshake, whereby the handshake
confers to the Peer assurances concerning some version of the Authenticators
identity. What it does imply is that the entire keying mechanism cannot be
contained within EAP, nor within AAA nor NASREQ, nor within the media
specification. The distribution of symmetric keys is one of those perverse
things that does not and cannot follow our normal partitioning of network
communication problems, which is why people nearly always make a complete
hash of it. I suggest adding the words "within EAP alone" to the quoted
sentence.

Proposed Resolution: Accept