Hi Ryan,
I understand the deprecation of subjectName in favor of SubjectAltName,
this makes sense to me now.
I'm still struggling a little with mapping subjectAltName and
subjectName certificate fields to peer and server identities. I think
the text you suggested for the server name subjectAltName mapping is
good:
[rmh] How about we change "A subjectAltName of type iPAdress MAY
be used
[rmh] in the server certificate." To "If a dnsName is not
available other
[rmh] field types (for example a subjectAltName of type iPAdress
or
[rmh] uniformResourceIdentifier) MAY be used.
I think we should have similar text for the peer name. There are cases
where either or both the EAP peer and EAP server may be devices that do
not have an RFC822 name or dnsName.
I am a bit concerned with the text for the subject DN. Why not use the
same field for both server and peer certificates? In my experience the
email address in a certificate subject DN is not always the best
identifier. Could CN be used instead of email address?
With regard to usage of OCSP, I understand the concern you raise.
However, the current practice of retrieving a CRL when attached to the
network and validating the accepted certificate seems to provide decent
protection. The OCSP in TLS approach is a better approach, but how much
better is it? A SHOULD is a fairly strong requirement and its use here
may affect how quickly this document can move through the standards
track. I want to make sure we are getting significant benefit from this
added requirement.
Joe
________________________________
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Monday, February 05, 2007 1:04 PM
To: emu@ietf.org
Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
Joe - For some reason I didn't get your email, I found it on the
archives; bellow are the questions from that mail and my answers:
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.
[Joe] Why subjectAltName and not Subject?
[rmh] The use of the subject name was intended to
represent a directory location, directory locations may or
may not include the a value that would reasonable
map to the subject id (eg a E rdn).
its bad form to require people to change their
directory layout to deploy a application, therefore
standards that take a dependency on a specific
name form being present in a certificate should do so
by specifying that name form exist in the
subjectAltName.
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.
[Joe] What is E RDN?
[rmh] RDN is a relative distinguished name, DNs are made
up of these;
There is a RDN is for the email address, I don't
have the X.500
documents handy but its defined in there. I
remember the name being
just E; however I did some googling and looks like
I was wrong its
emailAddress.
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.
[Joe] Are there other standards that are deprecating the
use of subject
field as well? (This is related to my first question
above.)
[rmh] uid is the only other RDN that a peer-id like
value that might be used in
[rmh] however in practice I have never seen this used;
see my other comment as
[rmh] to why. This is one of the reasons other rfcs like
TLS deprecate use of the
[rmh] subject dn for subjectAltName instead (see 3.1 of
http://www.ietf.org/rfc/rfc2818.txt)
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.
[Joe] There may be hosts which do not have a DNSName or
Ipaddress (L2
entities), so I think we need to clarify the above
text.
[rmh] This text does not preclude the inclusion of other
name forms
[rmh] it even allows for it by saying other types can be
included.
[rmh] It is important to encourage a name form be
included for interop sake
[rmh] dnsName and rfc822 is clearly the most common in
existing deployments
[rmh] so including it seems appropriate.
[rmh] There should be some text in the security
consideration section
[rmh] about the MITM risks associated with making a
trust decision
[rmh] on unauthenticated values you have at L2.
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.
[Joe] We probably need to allow various name types for
the server as
well. I think there still needs to be some discussion
on how
subjectAltNames map to peer and server names in the case
where there are
multiple subjectAltNames.
[rmh] How about we change "A subjectAltName of type
iPAdress MAY be used
[rmh] in the server certificate." To "If a dnsName is
not available other
[rmh] field types (for example a subjectAltName of type
iPAdress or
[rmh] uniformResourceIdentifier) MAY be used.
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.
[Joe] This is somewhat different than what the current
draft has
specified up until now. I am a little uneasy with OCSP
as a SHOULD,
are there other specifications which have such a strong
recommendation
for OCSP?
[rmh] I know of no other RFC that uses SHOULD for OCSP,
however I know of
[rmh] no other protocol in which its primary use case
prevents a client from
[rmh] checking the revocation status of the server. The
use of OCSP and TLS
[rmh] extensions enables this client to do this check.
[rmh] The SHOULD is a response to this security risk,
weaker wording would be
[rmh] the same as saying MAY choose to be vulnerable to
these attacks, SHOULD
[rmh] allows vendors to choose not to do so while
encouraging them to address
[rmh] these risks.
[rmh] There are also the latency and timing issues
associated with network connections
[rmh] make the download of 800k CRLs before a connect
can happen is a deal breaker,
[rmh] a few K (as little as 400 bytes) for a OCSP
response is a much better deal.
[rmh] I feel strongly the RFC needs to provide guidance
on how to use certificates
[rmh] securely and in a deployable way.
[rmh] I appreciate that not all implementations do this
but that is why its
[rmh] not a MUST.
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.
[Joe] A strong recommendation for TLS extensions is
somewhat counter to
some of the discussions we have had in the past about
keeping EAP-TLS as
bare bones as possible. I would like to hear other's
opinion on this.
[rmh] See my earlier comment on the security risks
associated with the use
[rmh] scenarios for this protocol, its dependency on
certificates at layer 2,
[rmh] and the clients inability to perform revocation
checking.
[rmh] The use of OCSP and the TLS extension addresses
this risk.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
