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 PROTECTED]
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
