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
