TOC 
NoneJ. Hodges
Internet-DraftNeuStar
Expires: August 16, 2008R. Morgan
 Internet2
 February 13, 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 16, 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
2.  Terminology
3.  Server Identity Check
    3.1.  Comparison of DNS Names
    3.2.  Comparison of IP Addresses
    3.3.  Comparison of Other subjectName Types
4.  References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

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] (Harrison, R., “Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms,” June 2006.) or its predecesor, [RFC2830] (Hodges, J., Morgan, R., and M. Wahl, “Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security,” May 2000.). [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] (Harrison, R., “Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms,” June 2006.), with the goal of becoming a stand-alone BCP document appropriately referenceable by I-Ds and thus RFCs.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

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.



 TOC 

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:

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.



 TOC 

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.



 TOC 

3.3.  Comparison of Other subjectName Types

Client implementations MAY support matching against subjectAltName values of other types as described in other documents.



 TOC 

4. References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML).
[RFC2830] Hodges, J., Morgan, R., and M. Wahl, “Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security,” RFC 2830, May 2000 (TXT).
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).
[RFC4346] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” RFC 4346, April 2006 (TXT).
[RFC4513] Harrison, R., “Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms,” RFC 4513, June 2006 (TXT).


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property