Bernard - I believe this block of text represents the changes we have
discussed in the thread, I would use it in your next release.
"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
emailAddress 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 a dnsName or rfc822Name are not available other field types
(for example a subjectAltName of type iPAdress 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. If a dnsName is not available
other field types (for example a subjectAltName of type iPAdress or
uniformResourceIdentifier) MAY be used.
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.
"
-----Original Message-----
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 1:12 PM
To: Bernard Aboba; [email protected]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
I will do this before I go home today.
-----Original Message-----
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 14, 2007 12:27 PM
To: [email protected]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
If possible, I'd like to include text arising from this thread in the
-08
version of the document, submitted by the IETF 68 deadline.
To make it easier for me to figure out what that text is, it would be
helpful for someone to post the suggested changes in their entirety,
with
modifications agreed to during the discussion. Further comments can
then
refer to that text, suggesting specific changes.
Having that record on the mailing list will make it a lot easier for me
to
figure out what changes to make to the document.
Thanks in advance,
Bernard
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
