Subject: [Emu] draft-simon-emu-rfc2716bis-07.txt

From: Ryan Hurst <[email-masked]>
Date: Thu, 1 Feb 2007 12:34:47 -0800

I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe that
compared with the -06 text, this version has taken a step backwards.  My
read of the -07 changes are that they remove obligations for RFC
conformant certificate validation and authorization, making RFC 2716bis
less secure than RFC 2716 combined with RFC 3280.  For this reason I
believe that draft -07 is not suitable for advancement as a Proposed
Standard.

To address the issues, I propose that the current Sections 5.2 and 5.3
be replaced with the following text:

"5.2 Peer and Server Identities

   The EAP-TLS peer name (Peer-Id) represents the identity to be 
   used for access control and accounting purposes.  The Server-Id 
   represents the identity of the EAP server.

   In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
   or subjectAltName fields in the peer and server certificates.  As
   noted in [RFC3280] Section 4.1.2.6.

   Where the subjectAltName field is present in the peer or server 
   certificate, the Peer-Id or Server-Id MUST be set to the contents 
   of the subjectAltName as per Section 5.3.  

   If subject naming information is present in only in the subject name
field

   then the Subject Field of the peer certificate SHOULD contain a E RDN

   containing the Peer-Id and the Subject Field of the server
certificate MUST

   contain the CN RDN containing the Server-ID.  If subject naming

   information is present only in the subjectAltName extension then the
subject

   field MUST be an empty sequence and the subjectAltName extension

   MUST be critical. 

   Although the use of  the subject field is existing practice, its use
in EAP-TLS

   is deprecated and Certification Authorities are encouraged to use 
   the subjectAltName field instead.

   Where the peer identity represents a host, a subjectAltName of type 
   dNSName SHOULD be present in the peer certificate.  Where the peer 
   identity represents a user and not a resource, a subjectAltName of
type
   rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. 
   If the peer identity represents neither a host nor a user, another
field

   type (for example a subjectAltName of type iPAddress
   or uniformResourceIdentifier) MAY be used. 

   A server identity will typically represent a host, not a user or
   a resource.  As a result, a subjectAltName of type dNSName SHOULD be
   present in the server certificate.  A subjectAltName of type
   iPAdress MAY be used in the server certificate. 

5.3.  Certificate Validation

   Since the EAP-TLS server is typically connected to the Internet,
   it SHOULD support validating the  peer certificate using 
   RFC 3280 [RFC3280] conformant path validation, including the 
   ability to retrieve intermediate certificates that may be
   necessary to validate the peer certificate. For details, 
   see [RFC3280] Section 4.2.2.1.

   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, it must be pre-configured with the necessary 
   intermediate certificates to complete path validation or 
   rely on the EAP-TLS peer to provide this information as 
   part of the TLS Handshake (see [RFC4346] section 7.4.6).

   In contrast to the EAP-TLS server, the EAP-TLS peer may
   not have Internet connectivity. Therefore the EAP-TLS server 
   SHOULD provide its entire certificate chain minus the root to 
   facilitate certificate validation by the peer.

   Once a TLS session is established EAP-TLS peer and server 
   implementations MUST validate that the identities represented 
   in the certificate are appropriate and authorized for 
   use with EAP-TLS.  The authorization process makes 
   use of the contents of the certificates as well 
   as other contextual information.  While authorization 
   requirements will vary from deployment to deployment 
   it is RECOMMENDED that implementations be able to 
   authorize based on the EAP-TLS Peer-Id and Server-Id 
   determined as described in Section 5.2. 

   In the case of the EAP-TLS peer this involves ensuring 
   that the certificate presented by the EAP-TLS server was 
   intended to be used as a server certificate.
   Implementations SHOULD use the Extended Key 
   Usage (see [RFC3280] section 4.2.1.13) 
   extension and ensure that at least one of the 
   following is true:

   1) The certificate issuer included no Extended Key Usage 
        identifiers in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier 
       in the certificate (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-serverAuth identifier 
       in the certificate (See [RFC3280] section 4.2.1.13).

   When performing this comparison implementations MUST follow the 
   validation rules specified in [RFC2818] Section 3.1.

   In the case of the server this involves ensuring the certificate 
   presented by the EAP-TLS peer was intended to be used as a 
   client certificate. Implementations SHOULD use the Extended 
   Key Usage (see [RFC3280] Section 4.2.1.13) extension and 
   ensure that at least one of the following is true:

   1) The certificate issuer included no Extended Key Usage identifiers
in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in the
certificate 
       (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-clientAuth identifier in the
certificate 
      (see [RFC3280] section 4.2.1.13).

5.4.  Certificate revocation

   Certificates are long lived assertions of identity. 
   Therefore it is important for EAP-TLS implementations to 
   be capable of checking whether these assertions have been 
   revoked. 
 
   EAP-TLS peer and server implementations MUST support the 
   use of Certificate Revocation Lists (CRLs); for details,
   see [RFC3280] section 3.3.  EAP-TLS peer and server 
   implementations SHOULD also support the Online 
   Certificate Status Protocol (OCSP), described in [RFC2560].
   OCSP messages are typically much smaller than CRLs which can shorten 
   connection times especially in bandwidth constrained environments.

   While EAP-TLS servers are typically connected to the Internet during
   the EAP conversation, an EAP-TLS peer may not have Internet
   connectivity until authentication completes. 

   In the case where the peer is initiating a voluntary Layer 2 tunnel
   using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically
   already have a PPP interface and Internet connectivity established at
   the time of tunnel initiation.

   However, in the case where the EAP-TLS peer is attempting to obtain
network
   access, it will not have network connectivity and is therefore not
   capable of checking for certificate revocation until after
   authentication completes and network connectivity is available.  

   For this reason EAP-TLS peers and servers SHOULD implement 
   Certificate Status Request messages, as described in [RFC3546] 
   section 3.6.  To enable revocation checking in situations 
   where servers do not support Certificate
   Status Request messages and network connectivity is not
   available prior to authentication completion,  peer 
   implementations SHOULD also support checking for certificate 
   revocation after authentication completes and network connectivity 
   is available, and SHOULD utilize this capability.

"

Ryan M. Hurst

Sr. Program Manager

Windows Enterprise Networking

[email-masked]

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 1 Feb 2007 14:12:17 -0800

Hi Ryan,
 
Thanks for posting this, I think it is very helpful.   I have some
questions in-line below:

________________________________

	From: Ryan Hurst [mailto:[email-masked]] 
	Sent: Thursday, February 01, 2007 12:35 PM
	To: [email-masked]
	Subject: [Emu] draft-simon-emu-rfc2716bis-07.txt

	I have reviewed draft-simon-emu-rfc2716bis-07.txt and believe
that compared with the -06 text, this version has taken a step
backwards.  My read of the -07 changes are that they remove obligations
for RFC conformant certificate validation and authorization, making RFC
2716bis less secure than RFC 2716 combined with RFC 3280.  For this
reason I believe that draft -07 is not suitable for advancement as a
Proposed Standard.

	To address the issues, I propose that the current Sections 5.2
and 5.3 be replaced with the following text:

	   used for access control and accounting purposes.  The
Server-Id 
	   represents the identity of the EAP server.

	   In EAP-TLS, the Peer-Id and Server-Id are determined from the
subject
	   or subjectAltName fields in the peer and server certificates.
As
	   noted in [RFC3280] Section 4.1.2.6.

	   Where the subjectAltName field is present in the peer or
server 
	   certificate, the Peer-Id or Server-Id MUST be set to the
contents 
	   of the subjectAltName as per Section 5.3.  

[Joe] Why subjectAltName and not Subject?  

	   If subject naming information is present in only in the
subject name field

	   then the Subject Field of the peer certificate SHOULD contain
a E RDN

	   contain the CN RDN containing the Server-ID.  If subject
naming

	   information is present only in the subjectAltName extension
then the subject

	   field MUST be an empty sequence and the subjectAltName
extension

	   MUST be critical. 

[Joe] What is E RDN?  

	   Although the use of  the subject field is existing practice,
its use in EAP-TLS

	   is deprecated and Certification Authorities are encouraged to
use 
	   the subjectAltName field instead.

[Joe] Are there other standards that are deprecating the use of subject
field as well?  (This is related to my first question above.)

	   Where the peer identity represents a host, a subjectAltName
of type 
	   dNSName SHOULD be present in the peer certificate.  Where the
peer 
	   identity represents a user and not a resource, a
subjectAltName of type
	   rfc822Name SHOULD be used, conforming to the grammar for the
	   Network Access Identifier (NAI) defined in [RFC4282] Section
2.1. 
	   If the peer identity represents neither a host nor a user,
another field

[Joe] There may be hosts which do not have a DNSName or Ipaddress (L2
entities), so I think we need to clarify the above text. 	 

	   A server identity will typically represent a host, not a user
or
	   a resource.  As a result, a subjectAltName of type dNSName
SHOULD be
	   present in the server certificate.  A subjectAltName of type
	   iPAdress MAY be used in the server certificate. 

[Joe] We probably need to allow various name types for the server as
well.  I think there still needs to be some discussion on how
subjectAltNames map to peer and server names in the case where there are
multiple subjectAltNames.  

	   Since the EAP-TLS server is typically connected to the
Internet,

	   When performing this comparison implementations MUST follow
the 
	   validation rules specified in [RFC2818] Section 3.1.

	   In the case of the server this involves ensuring the
certificate 

	   2) The issuer included the anyExtendedKeyUsage identifier in
the certificate 

	 
	   EAP-TLS peer and server implementations MUST support the 
	   use of Certificate Revocation Lists (CRLs); for details,
	   see [RFC3280] section 3.3.  EAP-TLS peer and server 
	   implementations SHOULD also support the Online 
	   Certificate Status Protocol (OCSP), described in [RFC2560].
	   OCSP messages are typically much smaller than CRLs which can
shorten 
	   connection times especially in bandwidth constrained
environments.

	   While EAP-TLS servers are typically connected to the Internet
during
	   the EAP conversation, an EAP-TLS peer may not have Internet
	   connectivity until authentication completes. 

[Joe]  This is somewhat different than what the current draft has
specified up until now.   I am a little uneasy with OCSP as a SHOULD,
are there other specifications which have such a strong recommendation
for OCSP?   

	   In the case where the peer is initiating a voluntary Layer 2
tunnel
	   using PPTP [RFC2637] or L2TP [RFC2661], the peer will
typically
	   already have a PPP interface and Internet connectivity
established at
	   the time of tunnel initiation.

	   However, in the case where the EAP-TLS peer is attempting to
obtain network
	   access, it will not have network connectivity and is
therefore not
	   capable of checking for certificate revocation until after
	   authentication completes and network connectivity is
available.  

	   For this reason EAP-TLS peers and servers SHOULD implement 
	   Certificate Status Request messages, as described in
[RFC3546] 
	   section 3.6.  To enable revocation checking in situations 
	   where servers do not support Certificate
	   Status Request messages and network connectivity is not
	   available prior to authentication completion,  peer 
	   implementations SHOULD also support checking for certificate 
	   revocation after authentication completes and network
connectivity 
	   is available, and SHOULD utilize this capability. 

[Joe] A strong recommendation for TLS extensions is somewhat counter to
some of the discussions we have had in the past about keeping EAP-TLS as
bare bones as possible.   I would like to hear other's opinion on this. 

	Ryan M. Hurst

	Sr. Program Manager

	[email-masked]