Comments in-line
-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 06, 2007 8:35 AM
To: Ryan Hurst; [email protected]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
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.
[rmh] Could you propose some text that would address your
concern?
[rmh] It was my hope that the following (from the original
proposal)
[rmh] would address this concern:
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.
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?
[rmh] CNs contain common names, for example my CN in the
directory is Ryan Hurst,
[rmh] this is the appropriate use of CN and as you can see this
is not non-ambiguous
[rmh] (there is a actor with the same name BTW).
[rmh] Since servers do not have "common names" it is has become
standard to put the
[rmh] DNS name in the common name field instead of using a
dNSName RDN (I am not even sure
[rmh] one exists).
[rmh] In the case of user certificates clearly users have common
names, and applications almost
[rmh] universally expect this field to be present for display
purposes. It's this reason the eMail
[rmh] address (when present in a DN) is put into its own RDN.
[rmh] The proposed text is consistent with all certificate
mapping implementations I have ever encountered,
[rmh] and it should also be consistent with the HTTP over SSL
RFC that prescribes much of the same.
[rmh] In the end applications have one of two choices when doing
mapping, map on the full subject DN or
[rmh] map on the email address and we should not specify
anything inconsistent with that as it will lead
[rmh] to problems.
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.
[rmh] I understand the concern, and it's certainly a tricky balance
trying to
[rmh] do what is right for security and keeping the process streamlined
but I would
[rmh] think it would be best for us to lean towards security vs. process
when crafting.
[rmh] documents like this. OCSP is nearly a decade old, there are a
dozen interoperable
[rmh] implementations out there TLS 1.1 (also several years old now)
which this document
[rmh] takes a normative reference to supports the exchange of OCSP
messages for this
[rmh] exact case.
[rmh] As for the OCSP stapling approach vs the post connect revocation
(CRL or OCSP)
[rmh] check approach, the difference is that with the OCSP approach you
get to know if
[rmh] your at risk before you present your credentials, etc but with the
post check approach
[rmh] you only know once the damage is done.
Joe
________________________________
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Monday, February 05, 2007 1:04 PM
To: [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
