Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 26 Oct 2006 22:02:55 -0700

Looks good to me. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Sunday, October 22, 2006 8:47 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> >The document should also state in the security 
> considerations section 
> >that the identity in the identity response is not 
> necessarily related 
> >to the identity authenticated in EAP-TLS and should not be 
> relied upon 
> >for any access control or accounting purposes.
> 
> Here is some proposed new text for Section 2.4:
> 
> "As noted in [RFC3748] Section 5.1:
> 
>    It is RECOMMENDED that the Identity Response be used primarily for
>    routing purposes and selecting which EAP method to use.  EAP
>    Methods SHOULD include a method-specific mechanism for obtaining
>    the identity, so that they do not have to rely on the Identity
>    Response.
> 
> As part of the TLS negotiation, the server presents a 
> certificate to the peer, and if mutual authentication is 
> requested, the peer presents a certificate to the server.  
> EAP-TLS therefore provides a mechanism for determining both 
> the peer identity (Peer-Id in [KEYFRAME]) and server identity 
> (Server-Id in [KEYFRAME]).
> Since the identity presented in the Identity Response need 
> not be related to the identity presented in the peer 
> certificate, EAP-TLS implementations SHOULD NOT require that 
> they be identical, and SHOULD NOT use the identity presented 
> in the Identity Response for access control or accounting purposes."
> 

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 26 Oct 2006 22:14:59 -0700

> Sent: Sunday, October 22, 2006 9:39 AM
> Joe Salowey said:
> >Currently the section states that the peer identity is obtained from 
> >the subjectAltName in the certificate.  Is this text meant to be 
> >normative?
> >Currently there are implementations
> >that use elements of the subject distinguished name and do 
> not provide 
> >a subjectAltName.
> >
> >Perhaps it would be better to say the subjectAltName is used 
> if it is 
> >present and if it is not then the subject distinguished name is used.
> >However it seems that RFC3280 might indicate that it would 
> be better to 
> >use subject distinguished name if it is present and subjectAltName if
> >not. This section should  reference RFC3280.   Also is there 
> any reason
> >why mapping using a directory service is called out, isn't 
> just mapping 
> >to a Peer-ID or Server-ID sufficient?
> >
> >It would may also be good to say that an EAP-TLS implementation MAY 
> >make other certificate fields available to the lower layer.
> 
> I've added some text in Section 4.2 that hopefully will clear this up:
> 
> 4.2.  Certificate Usage
> 
>    The EAP-TLS peer name (Peer-Id) represents the Network Access
>    Identifier (NAI) [RFC4282] to be used for authorization and
>    accounting purposes.  The Peer-Id is determined from the subject or
>    altSubjectName fields in the peer certificate.  As noted 
> in [RFC3280]
>    Section 4.1.2.6:
> 
>       The subject field identifies the entity associated with 
> the public
>       key stored in the subject public key field.  The 
> subject name MAY
>       be carried in the subject field and/or the subjectAltName
>       extension...  If subject naming information is present 
> only in the
>       subjectAltName extension (e.g., a key bound only to an email
>       address or URI), then the subject name MUST be an empty sequence
>       and the subjectAltName extension MUST be critical.
> 
>       Where it is non-empty, the subject field MUST contain an X.500
>       distinguished name (DN).
> 
>    Where the subject field is not empty, the Peer-Id and Server-Id are
>    obtained from the Common Name (CN) field of the DN.  Where subject
>    naming information is present only in the subjectAltName extension,
>    the Peer-Id and Server-Id are obtained from the subjectAltName.
> 
[Joe] OK

>    A valid EAP-TLS client certificate SHOULD contain an 
> extendedKeyUsage
>    value indicating support for Client Authentication
>    (1.3.6.1.5.5.7.3.2).  A valid EAP-TLS server certificate SHOULD
>    contain an extendedKeyUsage value indicating support for Server
>    Authentication (1.3.6.1.5.5.7.3.1).
> 
[Joe] I think I remember that some protocols specify the presence of a
specific EKU or the ANY EKU.

>    As discussed in [He], the security of EAP-TLS can be compromised if
>    the same credentials are used for authentication within multiple
>    applications.  

[Joe] I haven't looked at [He] in a while, but I thought that it wasn't
applications in general, but applications that use a protocol that
bindly signs arbitrary data. Perhaps this should be a bit clearer. 

>  Certificate extensions for use with EAP-TLS are
>    discussed in "Certificate Extensions and Attributes Supporting
>    Authentication in Point-to-Point Protocol (PPP) and Wireless Local
>    Area Networks (WLAN)" [RFC4334].  These extensions enable 
> certificate
>    usage to be restricted to use with lower layers such as 
> PPP or IEEE 802.11.
>    An EAP-TLS implementation MAY make these and other 
> certificate fields
>    available to the lower layer.
> 
[Joe] OK