eap Mailing List: Issue: Comments on draft-ietf-eap-keying-08b.txt section 1

[Salowey, Joe (jsalowey]

Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Reference: (this email)
Document: Keying Framework
Comment type: E
Priority: 1
Section: multiple in section 1


Section 1.3 

--
"The EAP server also stores the peer's identity and/or other information
necessary to decide whether access to some service should be granted. "


This sentence (appearing twice) makes it sound like the EAP server is
going to decide whether to access to a server should be granted.  It
would be better to say something like

"The EAP server also stores the peer's identity and/or other information
associated with the identity.  This information may be provided with the
authenticated identity to the entity that determines whether access to
the service that required EAP authentication should be granted."
--
Since IV is being deprecated I think we should reference it a little as
possible, suggestion is to remove refernces to IV in this section.  It
should be removed in figure 1. 
--
"EAP methods also MAY export method-specific peer and server
   identifiers (peer-ID and server-ID), a method-specific EAP
   conversation identifier known as the Method-ID, and the lifetime of
   the exported keys, known the Key-Lifetime.   EAP methods MAY also
   support the import and export of Channel Bindings.  New EAP method
   specifications MUST define the Peer-ID, Server-ID and Method-ID. The
   combination of the Peer-ID and Server-ID uniquely specifies the
   endpoints of the EAP method exchange."

It seems that additional data associated with the identity should be
exported to satisfy section 1.3.  Suggestion is to add this and call
them identity attributes.

In this paragraph the it states that the "Peer-ID and Server-ID uniquely
specifies the
   endpoints of the EAP method exchange", however further down it states
that these quantities may be null.  This is contradictory.  Suggested
modificaiton to above text:
"The combination of the Peer-ID and Server-ID may uniquely specify the
endpoints of the EAP method exchange if the method supports unique IDs."
--
There are two styles of channel bindings that may be supported by EAP
methods. The text in this section describes exportable channel bindings.
There is also the approach where the bindings are non exportable.  In
this case the method does a binary comparision of the channelbindings or
hash of the channel bindings and fails if the result does not match.  I
can see the possibility of a method supporting both styles.  Should we
include both?

---
Section 1.3.1
--- 

Should remove reference to IV

--
Section 1.4 
---

Exportable channel binding are references in this section,
non-exportable ones are not.  If we make changes to this affect above
then we should change it here as well. 
---