Subject: pp7: draft-hodges-server-ident-check-00.txt

From: ' =JeffH ' <[email-masked]>
Date: Sun, 10 Feb 2008 12:19:08 -0800

Here's an I-D fresh off the press wrt pp7 - "Server Identity Check". I've also 
submitted it to the I-D repository.

=JeffH
------

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: [email-masked]

   RL 'Bob' Morgan
   UWashington/Internet2
   Seattle, WA
   US

   Email: [email-masked]

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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hodges & Morgan          Expires August 13, 2008                [Page 9]

---
end