In-line
-----Original Message-----
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 10:03 PM
To: [email protected]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
>From the discussion it seems that if OCSP is a SHOULD implement, then
we
need a MUST for revocation checking after authentication, since some
servers
might not implement OCSP, right? I don't think we can add "MUST use"
text
for something that is a "SHOULD implement".
In terms of usage, it is possible for the Peer-Id to represent a machine
name. For example, with EAP-TLS the peer could use a machine
certificate
for authentication. So I think that the text on subjectAltName as well
as
the subject name field needs to reflect this.
BTW, I'm not entirely clear that the NAI syntax is completely compatible
with that of an email address, although they are pretty close. For
example,
RFC 4282 defines internationalization of the username field in the NAI,
but
for email addresses we aren't there yet. This has come up in other
contexts
too (e.g. IKEv2 Identity Payload) where it turned out not to be a big
deal,
but I thought it was worth pointing out, just in case someone knows
otherwise.
On the server side, I don't think that the Server-Id is likely to be an
NAI,
although I'm not sure we can prohibit that.
Based on the comments and my own cleanup, here is where I think we are
at
the moment.
Comments welcome.
=====================================================
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:
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).
[rmh] We do not universally quote deep references in this document, what
criteria are being applied to determine which references will warrant a
reference + quote vs. just a reference?
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 only in the subjectAltName extension of a peer or server
certificate, 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.
If subject naming information is present only in the subject name
field and the peer identity represents a user, then the subject name
field SHOULD contain an emailAddress RDN. If the peer identity
represents a host or device the subject name field SHOULD contain a
CN RDN or Serial Number RDN.
[rmh] If you say they can include a serialNumber (not Serial Number) RDN
then you have to specify processing symantics when more than one are
present, and discuss what sort of value is used here, etc.
[rmh] I suggest dropping the " or Serial Number RDN" portion of this
text, we can if appropriate work on a appendix or other RFC that
discusses these issues; I suspect the right answer will be to reference
the Permanent Identifier RFC from the PKIX working group which already
deals with these problems.
If subject naming information is present only in the subject name
field of a server certificate, then the subject name field MUST
contain a CN RDN or Serial Number RDN.
[rmh] See my prior statements on serialNumber RDN.
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 MUST also support checking for
certificate revocation after authentication completes and network
connectivity is available, and they SHOULD utilize this capability by
default.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
