Internet DRAFT - draft-hodges-server-ident-check
draft-hodges-server-ident-check
None J. Hodges
Internet-Draft NeuStar
Expires: August 13, 2008 R. Morgan
Internet2
February 10, 2008
Generic Server Identity Check
draft-hodges-server-ident-check-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Hodges & Morgan Expires August 13, 2008 [Page 1]
Internet-Draft Server Ident Check February 2008
Abstract
This document specifies the how an entity establishing a TLS
connection, or other PKI-based interaction, with a server should
verify the server identity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Server Identity Check . . . . . . . . . . . . . . . . . . . . . 5
3.1. Comparison of DNS Names . . . . . . . . . . . . . . . . . . 6
3.2. Comparison of IP Addresses . . . . . . . . . . . . . . . . 6
3.3. Comparison of Other subjectName Types . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hodges & Morgan Expires August 13, 2008 [Page 2]
Internet-Draft Server Ident Check February 2008
1. Introduction
Establishing a TLS-based connection with a server, or any other sort
of client-server PKI-based interaction, entails, on the part of the
client, verifying the "server's identity" based upon information
presented by the server in its certificate correlated with the
information about the server ensconced in the Domain Name System
(DNS).
Presently, various Internet-Drafts utilizing TLS or prescribing PKI-
based interactions, either prescribe their own server identity check,
or reference [RFC4513] or its predecesor, [RFC2830]. [there may be
other I-Ds referencing other specs that describe the equivalent of
server identity checks]
Converging our present understanding of this critical aspect of PKI-
based interactions is desirable in that it will hopefully encourage
more coherence in specifications and actual implementations thereof,
as well as ease the burden of crafting new specifications because
this aspect has been factored out and separately standardized.
This document extracts the "server identity check" section from
[RFC4513], with the goal of becoming a stand-alone BCP document
appropriately referenceable by I-Ds and thus RFCs.
Hodges & Morgan Expires August 13, 2008 [Page 3]
Internet-Draft Server Ident Check February 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Hodges & Morgan Expires August 13, 2008 [Page 4]
Internet-Draft Server Ident Check February 2008
3. Server Identity Check
In order to prevent man-in-the-middle attacks, the client MUST verify
the server's identity (as presented in the server's Certificate
message). In this section, the client's understanding of the
server's identity (typically the identity used to establish the
transport connection) is called the "reference identity".
The client may map the reference identity to a different type prior
to performing a comparison. Mappings may be performed for all
available subjectAltName types to which the reference identity can be
mapped; however, the reference identity should only be mapped to
types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure
manner (e.g., using DNSSEC, or using user- or admin-configured host-
to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the reference
identity to the Common Name (CN) [RFC4519] value in the leaf Relative
Distinguished Name (RDN) of the subjectName field of the server's
certificate. This comparison is performed using the rules for
comparison of DNS names in Section 3.1.3.1, below, with the exception
that no wildcard matching is allowed. Although the use of the Common
Name value is existing practice, it is deprecated, and Certification
Authorities are encouraged to provide subjectAltName values instead.
Note that the TLS implementation may represent DNs in certificates
according to X.500 or other conventions. For example, some X.500
implementations order the RDNs in a DN using a left-to-right (most
significant to least significant) convention instead of LDAP's right-
to-left convention.
If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport
connection and indicate that the server's identity is suspect.
Automated clients SHOULD close the transport connection and then
return or log an error indicating that the server's identity is
suspect or both.
Beyond the server identity check described in this section, clients
should be prepared to do further checking to ensure that the server
is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
Hodges & Morgan Expires August 13, 2008 [Page 5]
Internet-Draft Server Ident Check February 2008
3.1. Comparison of DNS Names
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
before comparison with subjectAltName values of type dNSName.
Specifically, conforming implementations MUST perform the conversion
operation specified in Section 4 of RFC 3490 as follows:
o in step 1, the domain name SHALL be considered a "stored string";
o in step 3, set the flag called "UseSTD3ASCIIRules";
o in step 4, process each label with the "ToASCII" operation; and
o in step 5, change all label separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in
Section 3 of RFC3490.
The '*' (ASCII 42) wildcard character is allowed in subjectAltName
values of type dNSName, and then only as the left-most (least
significant) DNS label in that value. This wildcard matches any
left-most DNS label in the server name. That is, the subject
*.example.com matches the server names a.example.com and
b.example.com, but does not match example.com or a.b.example.com.
3.2. Comparison of IP Addresses
When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
octet string will contain exactly four octets. For IP Version 6, as
specified in RFC 2460, the octet string will contain exactly sixteen
octets. This octet string is then compared against subjectAltName
values of type iPAddress. A match occurs if the reference identity
octet string and value octet strings are identical.
3.3. Comparison of Other subjectName Types
Client implementations MAY support matching against subjectAltName
values of other types as described in other documents.
Hodges & Morgan Expires August 13, 2008 [Page 6]
Internet-Draft Server Ident Check February 2008
4. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4513] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security Mechanisms",
RFC 4513, June 2006.
Hodges & Morgan Expires August 13, 2008 [Page 7]
Internet-Draft Server Ident Check February 2008
Authors' Addresses
Jeff Hodges
NeuStar
2000 Broadway Street
Redwood City, CA 94063
US
Email: Jeff.Hodges@neustar.biz
RL 'Bob' Morgan
UWashington/Internet2
Seattle, WA
US
Email: rlmorgan@washington.edu
Hodges & Morgan Expires August 13, 2008 [Page 8]
Internet-Draft Server Ident Check February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hodges & Morgan Expires August 13, 2008 [Page 9]
