Hi Ryan,
Thanks for posting this, I think it is very helpful. I have some
questions in-line below:
________________________________
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 01, 2007 12:35 PM
To: [email protected]
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:
"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.
[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
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.
[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
type (for example a subjectAltName of type iPAddress
or uniformResourceIdentifier) MAY be used.
[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.
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.
[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
Windows Enterprise Networking
[EMAIL PROTECTED]
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
