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

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

Hi Bernard,

Thanks for the update.  I'd like to have some discussion on section 2.4
- Identity verification.  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.

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. 

Joe

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 6:57 PM
> To: [email-masked]
> Subject: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt
> 
> I have updated RFC 2716bis with a list of changes, added a 
> section on privacy, rewritten the key hierarchy section to 
> utilize modern terminology (MSK, EMSK), and updated the 
> security considerations section.
> 
> The updated document is available here:
> http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-03.txt
> 
> Comments welcome.
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 22 Oct 2006 08:46:37 -0700

>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."

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 22 Oct 2006 09:38:55 -0700

Joe Salowey said:

>Currently the section states that the peer

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.

   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).

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