This text looks fine to me. > -----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). > > 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. > > 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. > > 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
