Subject: [Emu] draft-simon-emu-rfc2716bis-01

From: "Salowey, Joe" <[email-masked]>
Date: Sun, 16 Apr 2006 21:49:02 -0700

I think this draft is a good start.  At the meeting at IETF 65 the
working group desired to take this draft as a working group item.  Would
the authors submit this draft as draft-ietf-emu-rfc2716bis-00.txt.

Comments on the draft:

1. Section 2.4 Identity verification

The document specifies that the peer as server ID is carried in the
subjectAltName extension.  

A. It is possible that this extension may be empty and the name be
carried in the subjectName.  Should this be taken into account?  What is
the format of the ID, is it represented in ASN.1 format?  

B. It seems that there may be more than one SubjectAltName.  Are both
used as the ID?  It seems that order would matter for constructing a key
name.  

C. This document should probably reference RFC 3280. 

D. I think the last paragraph might not be quite correct:

"... Please note that in the case where the EAP authentication is
remoted that
   the EAP server will not reside on the same machine as the
   authenticator, and therefore the name in the EAP server's certificate
   cannot be expected to match that of the intended destination. In this
   case, a more appropriate test might be whether the EAP server's
   certificate is signed by a CA controlling the intended destination
   and whether the EAP server exists within a target sub-domain."

I'm not quite sure what the is meant by "target sub-domain."  In any
case it is important that the peer be able to authorize the server as an
EAP-Server that can authorize the authenticator the peer is connecting
to. This is more than being issued by an organizational CA since that
particular CA may issue certificates for many purposes. There either
needs to be something in the certificate or the peer must have
configuration to be able to perform the authorization.  

2. Section 2.5 Key Hierarchy

A.  Why is the EMSK broken into two halves?  It should not be as this
implies a particular usage for the EMSK.  It should just be one 64 byte
value.

B. Does this section tie the implementation of the PRF 10 2246?  What if
TLS 1.2 supports a different PRF? 

C. This section shoes the TLS key hierarchy, shouldn't it show the
EAP-TLS key hierarchy?

3. Section 2.6 Ciphersuite negotiation

A. At the SAAG meeting in IETF 65 Sam brought up an issue with multiple
layers of negotiation with EAP-TLS.  Is there a vulnerability introduced
by multiple levels of negotiation?  Is it possible that an peer or
server will negotiate a weaker authentication method though the
negotiation of TLS ciphersuites than it would through EAP negotiation?

B. The draft does not seem to specify which ciphersuites it is intended
to be used with.  Should it?

4. General 

The document should define a Method-ID (for computing session-ID and key
names).  The method ID could be as simple as the concatenation of the
server and client Finished messages. (these hashes contain the Client
and Hello Random's as well as the identities exchanged in the
certificates).  

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu