Joe Salowey said:
Currently the section states that the peer
identity is obtained from the subjectAltName in the certificate. Is
this text meant to be normative?
Currently there are implementations
that use elements of the subject distinguished name and do not provide a
subjectAltName.
Perhaps it would be better to say the subjectAltName is used if it is
present and if it is not then the subject distinguished name is used.
However it seems that RFC3280 might indicate that it would be better to
use subject distinguished name if it is present and subjectAltName if
not. This section should reference RFC3280. Also is there any reason
why mapping using a directory service is called out, isn't just mapping
to a Peer-ID or Server-ID sufficient?
It would may also be good to say that an EAP-TLS implementation MAY make
other certificate fields available to the lower layer.
I've added some text in Section 4.2 that hopefully will clear this up:
4.2. Certificate Usage
The EAP-TLS peer name (Peer-Id) represents the Network Access
Identifier (NAI) [RFC4282] to be used for authorization and
accounting purposes. The Peer-Id is determined from the subject or
altSubjectName fields in the peer certificate. 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 subject field is not empty, the Peer-Id and Server-Id are
obtained from the Common Name (CN) field of the DN. Where subject
naming information is present only in the subjectAltName extension,
the Peer-Id and Server-Id are obtained from the subjectAltName.
A valid EAP-TLS client certificate SHOULD contain an extendedKeyUsage
value indicating support for Client Authentication
(1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD
contain an extendedKeyUsage value indicating support for Server
Authentication (1.3.6.1.5.5.7.3.1).
As discussed in [He], the security of EAP-TLS can be compromised if
the same credentials are used for authentication within multiple
applications. Certificate extensions for use with EAP-TLS are
discussed in "Certificate Extensions and Attributes Supporting
Authentication in Point-to-Point Protocol (PPP) and Wireless Local
Area Networks (WLAN)" [RFC4334]. These extensions enable certificate
usage to be restricted to use with lower layers such as PPP or IEEE
802.11.
An EAP-TLS implementation MAY make these and other certificate fields
available to the lower layer.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
