tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6125

 
 
 

Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

Part 3 of 3, p. 40 to 57
Prev RFC Part

 


prevText      Top      Up      ToC       Page 40 
Appendix A.  Sample Text

   At the time of this writing, two application technologies reuse the
   recommendations in this specification: email [EMAIL-SRV] and XMPP
   [XMPP].  Here we include the text from [XMPP] to illustrate the
   thought process that might be followed by protocol designers for
   other application technologies.  Specifically, because XMPP uses DNS
   SRV records for resolution of the DNS domain names for application
   services, the XMPP specification recommends the use of SRV-IDs.

   The text regarding certificate issuance is as follows:

   ######

   In a PKIX certificate to be presented by an XMPP server (i.e., a
   "server certificate"), the certificate MUST include one or more XMPP
   addresses (i.e., domainparts) associated with XMPP services hosted at
   the server.  The rules and guidelines defined in [this specification]
   apply to XMPP server certificates, with the following XMPP-specific
   considerations:

   o  Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
      client and server software implementations.  Certification
      authorities that issue XMPP-specific certificates MUST support the
      DNS-ID identifier type.  XMPP service providers SHOULD include the
      DNS-ID identifier type in certificate requests.

   o  Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for
      XMPP client and server software implementations (for verification
      purposes XMPP client implementations need to support only the
      "_xmpp-client" application service type, whereas XMPP server
      implementations need to support both the "_xmpp-client" and
      "_xmpp-server" application service types).  Certification
      authorities that issue XMPP-specific certificates SHOULD support
      the SRV-ID identifier type.  XMPP service providers SHOULD include
      the SRV-ID identifier type in certificate requests.

   o  Support for the XmppAddr identifier type is encouraged in XMPP
      client and server software implementations for the sake of
      backward-compatibility, but is no longer encouraged in
      certificates issued by certification authorities or requested by
      XMPP service providers.

   o  DNS domain names in server certificates MAY contain the wildcard
      character '*' as the complete left-most label within the
      identifier.

   ######

Top      Up      ToC       Page 41 
   The text regarding certificate verification is as follows:

   ######

   For server certificates, the rules and guidelines defined in [this
   specification] apply, with the proviso that the XmppAddr identifier
   is allowed as a reference identifier.

   The identities to be checked are set as follows:

   o  The initiating entity sets its reference identifier to the 'to'
      address it communicates in the initial stream header; i.e., this
      is the identity it expects the receiving entity to provide in a
      PKIX certificate.

   o  The receiving entity sets its reference identifier to the 'from'
      address communicated by the initiating entity in the initial
      stream header; i.e., this is the identity that the initiating
      entity is trying to assert.

   ######

Top      Up      ToC       Page 42 
Appendix B.  Prior Art

   (This section is non-normative.)

   The recommendations in this document are an abstraction from
   recommendations in specifications for a wide range of application
   protocols.  For the purpose of comparison and to delineate the
   history of thinking about application service identity verification
   within the IETF, this informative section gathers together prior art
   by including the exact text from various RFCs (the only modifications
   are changes to the names of several references to maintain coherence
   with the main body of this document, and the elision of irrelevant
   text as marked by the characters "[...]").

B.1.  IMAP, POP3, and ACAP (1999)

   In 1999, [USINGTLS] specified the following text regarding
   application service identity verification in IMAP, POP3, and ACAP:

   ######

   2.4.  Server Identity Check

   During the TLS negotiation, the client MUST check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent man-in-the-middle
   attacks.  Matching is performed according to these rules:

   o  The client MUST use the server hostname it used to open the
      connection as the value to compare against the server name as
      expressed in the server certificate.  The client MUST NOT use any
      form of the server hostname derived from an insecure remote source
      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the left-most name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc. but would not match
      example.com.

   o  If the certificate contains multiple names (e.g. more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

Top      Up      ToC       Page 43 
   If the match fails, the client SHOULD either ask for explicit user
   confirmation, or terminate the connection and indicate the server's
   identity is suspect.

   ######

B.2.  HTTP (2000)

   In 2000, [HTTP-TLS] specified the following text regarding
   application service identity verification in HTTP:

   ######

   3.1.  Server Identity

   In general, HTTP/TLS requests are generated by dereferencing a URI.
   As a consequence, the hostname for the server is known to the client.
   If the hostname is available, the client MUST check it against the
   server's identity as presented in the server's Certificate message,
   in order to prevent man-in-the-middle attacks.

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.  (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)  In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
   in the middle attacks.  In special cases, it may be appropriate for
   the client to simply ignore the server's identity, but it must be
   understood that this leaves the connection open to active attack.

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used.  Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
   [PKIX-OLD].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.)  Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment.  E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

   In some cases, the URI is specified as an IP address rather than a
   hostname.  In this case, the iPAddress subjectAltName must be present
   in the certificate and must exactly match the IP in the URI.

Top      Up      ToC       Page 44 
   If the hostname does not match the identity in the certificate, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error.  Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

   Note that in many cases the URI itself comes from an untrusted
   source.  The above-described check provides no protection against
   attacks where this source is compromised.  For example, if the URI
   was obtained by clicking on an HTML page which was itself obtained
   without using HTTP/TLS, a man in the middle could have replaced the
   URI.  In order to prevent this form of attack, users should carefully
   examine the certificate presented by the server to determine if it
   meets their expectations.

   ######

B.3.  LDAP (2000/2006)

   In 2000, [LDAP-TLS] specified the following text regarding
   application service identity verification in LDAP:

   ######

   3.6.  Server Identity Check

   The client MUST check its understanding of the server's hostname
   against the server's identity as presented in the server's
   Certificate message, in order to prevent man-in-the-middle attacks.

   Matching is performed according to these rules:

   o  The client MUST use the server hostname it used to open the LDAP
      connection as the value to compare against the server name as
      expressed in the server's certificate.  The client MUST NOT use
      the server's canonical DNS name or any other derived form of name.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  The "*" wildcard character is allowed.  If present, it applies
      only to the left-most name component.

Top      Up      ToC       Page 45 
   E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
   bar.com.  If more than one identity of a given type is present in the
   certificate (e.g. more than one dNSName name), a match in any one of
   the set is considered acceptable.

   If the hostname does not match the dNSName-based identity in the
   certificate per the above check, user-oriented clients SHOULD either
   notify the user (clients MAY give the user the opportunity to
   continue with the connection in any case) or terminate the connection
   and indicate that the server's identity is suspect.  Automated
   clients SHOULD close the connection, returning and/or logging an
   error indicating that the server's identity is suspect.

   Beyond the server identity checks 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 observed to provide.  The
   client MAY need to make use of local policy information.

   ######

   In 2006, [LDAP-AUTH] specified the following text regarding
   application service identity verification in LDAP:

   ######

   3.1.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 determines the type (e.g., DNS name or IP address) of the
   reference identity and performs a comparison between the reference
   identity and each subjectAltName value of the corresponding type
   until a match is produced.  Once a match is produced, the server's
   identity has been verified, and the server identity check is
   complete.  Different subjectAltName types are matched in different
   ways.  Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
   various subjectAltName types.

   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

Top      Up      ToC       Page 46 
   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) [LDAP-SCHEMA] value in the last
   Relative Distinguished Name (RDN) of the subject field of the
   server's certificate (where "last" refers to the DER-encoded order,
   not the order of presentation in a string representation of DER-
   encoded data).  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.

   3.1.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
   [IDNA2003] 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

Top      Up      ToC       Page 47 
   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.1.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
   [IP] [IPv6].  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.1.3.3.  Comparison of Other subjectName Types

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

   ######

B.4.  SMTP (2002/2007)

   In 2002, [SMTP-TLS] specified the following text regarding
   application service identity verification in SMTP:

   ######

   4.1 Processing After the STARTTLS Command

   [...]

   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter.  However, some
   general rules for the decisions are:

Top      Up      ToC       Page 48 
   o  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.

   [...]

   ######

   In 2006, [SMTP-AUTH] specified the following text regarding
   application service identity verification in SMTP:

   ######

   14.  Additional Requirements When Using SASL PLAIN over TLS

   [...]

   After a successful [TLS] negotiation, the client MUST check its
   understanding of the server hostname against the server's identity as
   presented in the server Certificate message, in order to prevent man-
   in-the-middle attacks.  If the match fails, the client MUST NOT
   attempt to authenticate using the SASL PLAIN mechanism.  Matching is
   performed according to the following rules:

      The client MUST use the server hostname it used to open the
      connection as the value to compare against the server name as
      expressed in the server certificate.  The client MUST NOT use any
      form of the server hostname derived from an insecure remote source
      (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

      If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

      Matching is case-insensitive.

      A "*" wildcard character MAY be used as the leftmost name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

      If the certificate contains multiple names (e.g., more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

   ######

Top      Up      ToC       Page 49 
B.5.  XMPP (2004)

   In 2004, [XMPP-OLD] specified the following text regarding
   application service identity verification in XMPP:

   ######

   14.2.  Certificate Validation

   When an XMPP peer communicates with another peer securely, it MUST
   validate the peer's certificate.  There are three possible cases:

   Case #1:  The peer contains an End Entity certificate which appears
      to be certified by a certification path terminating in a trust
      anchor (as described in Section 6.1 of [PKIX]).

   Case #2:  The peer certificate is certified by a Certificate
      Authority not known to the validating peer.

   Case #3:  The peer certificate is self-signed.

   In Case #1, the validating peer MUST do one of two things:

   1.  Verify the peer certificate according to the rules of [PKIX].
       The certificate SHOULD then be checked against the expected
       identity of the peer following the rules described in [HTTP-TLS],
       except that a subjectAltName extension of type "xmpp" MUST be
       used as the identity if present.  If one of these checks fails,
       user-oriented clients MUST either notify the user (clients MAY
       give the user the opportunity to continue with the connection in
       any case) or terminate the connection with a bad certificate
       error.  Automated clients SHOULD terminate the connection (with a
       bad certificate error) and log the error to an appropriate audit
       log.  Automated clients MAY provide a configuration setting that
       disables this check, but MUST provide a setting that enables it.

   2.  The peer SHOULD show the certificate to a user for approval,
       including the entire certification path.  The peer MUST cache the
       certificate (or some non-forgeable representation such as a
       hash).  In future connections, the peer MUST verify that the same
       certificate was presented and MUST notify the user if it has
       changed.

   In Case #2 and Case #3, implementations SHOULD act as in (2) above.

   ######

Top      Up      ToC       Page 50 
   Although [XMPP-OLD] defined its own rules, [XMPP] reuses the rules in
   this document regarding application service identity verification in
   XMPP.

B.6.  NNTP (2006)

   In 2006, [NNTP-TLS] specified the following text regarding
   application service identity verification in NNTP:

   ######

   5.  Security Considerations

   [...]

   During the TLS negotiation, the client MUST check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent man-in-the-middle
   attacks.  Matching is performed according to these rules:

   o  The client MUST use the server hostname it used to open the
      connection (or the hostname specified in TLS "server_name"
      extension [TLS]) as the value to compare against the server name
      as expressed in the server certificate.  The client MUST NOT use
      any form of the server hostname derived from an insecure remote
      source (e.g., insecure DNS lookup).  CNAME canonicalization is not
      done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it SHOULD be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the left-most name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

   o  If the certificate contains multiple names (e.g., more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

   If the match fails, the client SHOULD either ask for explicit user
   confirmation or terminate the connection with a QUIT command and
   indicate the server's identity is suspect.

Top      Up      ToC       Page 51 
   Additionally, clients MUST verify the binding between the identity of
   the servers to which they connect and the public keys presented by
   those servers.  Clients SHOULD implement the algorithm in Section 6
   of [PKIX] for general certificate validation, but MAY supplement that
   algorithm with other validation methods that achieve equivalent
   levels of verification (such as comparing the server certificate
   against a local store of already-verified certificates and identity
   bindings).

   ######

B.7.  NETCONF (2006/2009)

   In 2006, [NETCONF-SSH] specified the following text regarding
   application service identity verification in NETCONF:

   ######

   6.  Security Considerations

   The identity of the server MUST be verified and authenticated by the
   client according to local policy before password-based authentication
   data or any configuration or state data is sent to or received from
   the server.  The identity of the client MUST also be verified and
   authenticated by the server according to local policy to ensure that
   the incoming client request is legitimate before any configuration or
   state data is sent to or received from the client.  Neither side
   should establish a NETCONF over SSH connection with an unknown,
   unexpected, or incorrect identity on the opposite side.

   ######

   In 2009, [NETCONF-TLS] specified the following text regarding
   application service identity verification in NETCONF:

   ######

   3.1.  Server Identity

   During the TLS negotiation, the client MUST carefully examine the
   certificate presented by the server to determine if it meets the
   client's expectations.  Particularly, the client MUST check its
   understanding of the server hostname against the server's identity as
   presented in the server Certificate message, in order to prevent man-
   in-the-middle attacks.

Top      Up      ToC       Page 52 
   Matching is performed according to the rules below (following the
   example of [NNTP-TLS]):

   o  The client MUST use the server hostname it used to open the
      connection (or the hostname specified in the TLS "server_name"
      extension [TLS]) as the value to compare against the server name
      as expressed in the server certificate.  The client MUST NOT use
      any form of the server hostname derived from an insecure remote
      source (e.g., insecure DNS lookup).  CNAME canonicalization is not
      done.

   o  If a subjectAltName extension of type dNSName is present in the
      certificate, it MUST be used as the source of the server's
      identity.

   o  Matching is case-insensitive.

   o  A "*" wildcard character MAY be used as the leftmost name
      component in the certificate.  For example, *.example.com would
      match a.example.com, foo.example.com, etc., but would not match
      example.com.

   o  If the certificate contains multiple names (e.g., more than one
      dNSName field), then a match with any one of the fields is
      considered acceptable.

   If the match fails, the client MUST either ask for explicit user
   confirmation or terminate the connection and indicate the server's
   identity is suspect.

   Additionally, clients MUST verify the binding between the identity of
   the servers to which they connect and the public keys presented by
   those servers.  Clients SHOULD implement the algorithm in Section 6
   of [PKIX] for general certificate validation, but MAY supplement that
   algorithm with other validation methods that achieve equivalent
   levels of verification (such as comparing the server certificate
   against a local store of already-verified certificates and identity
   bindings).

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted.

   ######

B.8.  Syslog (2009)

   In 2009, [SYSLOG-TLS] specified the following text regarding
   application service identity verification in Syslog:

Top      Up      ToC       Page 53 
   ######

   5.2.  Subject Name Authorization

   Implementations MUST support certification path validation [PKIX].
   In addition, they MUST support specifying the authorized peers using
   locally configured host names and matching the name against the
   certificate as follows.

   o  Implementations MUST support matching the locally configured host
      name against a dNSName in the subjectAltName extension field and
      SHOULD support checking the name against the common name portion
      of the subject distinguished name.

   o  The '*' (ASCII 42) wildcard character is allowed in the dNSName of
      the subjectAltName extension (and in common name, if used to store
      the host name), but 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.  Implementations MUST
      support wildcards in certificates as specified above, but MAY
      provide a configuration option to disable them.

   o  Locally configured names MAY contain the wildcard character to
      match a range of values.  The types of wildcards supported MAY be
      more flexible than those allowed in subject names, making it
      possible to support various policies for different environments.
      For example, a policy could allow for a trust-root-based
      authorization where all credentials issued by a particular CA
      trust root are authorized.

   o  If the locally configured name is an internationalized domain
      name, conforming implementations MUST convert it to the ASCII
      Compatible Encoding (ACE) format for performing comparisons, as
      specified in Section 7 of [PKIX].

   o  Implementations MAY support matching a locally configured IP
      address against an iPAddress stored in the subjectAltName
      extension.  In this case, the locally configured IP address is
      converted to an octet string as specified in [PKIX], Section
      4.2.1.6.  A match occurs if this octet string is equal to the
      value of iPAddress in the subjectAltName extension.

   ######

Top      Up      ToC       Page 54 
B.9.  SIP (2010)

   In 2010, [SIP-CERTS] specified the following text regarding
   application service identity verification in SIP:

   ######

   7.2.  Comparing SIP Identities

   When an implementation (either client or server) compares two values
   as SIP domain identities:

      Implementations MUST compare only the DNS name component of each
      SIP domain identifier; an implementation MUST NOT use any scheme
      or parameters in the comparison.

      Implementations MUST compare the values as DNS names, which means
      that the comparison is case insensitive as specified by
      [DNS-CASE].  Implementations MUST handle Internationalized Domain
      Names (IDNs) in accordance with Section 7.2 of [PKIX].

      Implementations MUST match the values in their entirety:

         Implementations MUST NOT match suffixes.  For example,
         "foo.example.com" does not match "example.com".

         Implementations MUST NOT match any form of wildcard, such as a
         leading "." or "*." with any other DNS label or sequence of
         labels.  For example, "*.example.com" matches only
         "*.example.com" but not "foo.example.com".  Similarly,
         ".example.com" matches only ".example.com", and does not match
         "foo.example.com."

            [HTTP-TLS] allows the dNSName component to contain a
            wildcard; e.g., "DNS:*.example.com".  [PKIX], while not
            disallowing this explicitly, leaves the interpretation of
            wildcards to the individual specification.  [SIP] does not
            provide any guidelines on the presence of wildcards in
            certificates.  Through the rule above, this document
            prohibits such wildcards in certificates for SIP domains.

   ######

Top      Up      ToC       Page 55 
B.10.  SNMP (2010)

   In 2010, [SNMP-TLS] specified the following text regarding
   application service identity verification in SNMP:

   ######

   If the server's presented certificate has passed certification path
   validation [PKIX] to a configured trust anchor, and an active row
   exists with a zero-length snmpTlstmAddrServerFingerprint value, then
   the snmpTlstmAddrServerIdentity column contains the expected host
   name.  This expected host name is then compared against the server's
   certificate as follows:

   o  Implementations MUST support matching the expected host name
      against a dNSName in the subjectAltName extension field and MAY
      support checking the name against the CommonName portion of the
      subject distinguished name.

   o  The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName
      of the subjectAltName extension (and in common name, if used to
      store the host name), but 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.
      Implementations MUST support wildcards in certificates as
      specified above, but MAY provide a configuration option to disable
      them.

   o  If the locally configured name is an internationalized domain
      name, conforming implementations MUST convert it to the ASCII
      Compatible Encoding (ACE) format for performing comparisons, as
      specified in Section 7 of [PKIX].

   If the expected host name fails these conditions then the connection
   MUST be closed.

   ######

B.11.  GIST (2010)

   In 2010, [GIST] specified the following text regarding application
   service identity verification in the General Internet Signalling
   Transport:

Top      Up      ToC       Page 56 
   ######

   5.7.3.1.  Identity Checking in TLS

   After TLS authentication, a node MUST check the identity presented by
   the peer in order to avoid man-in-the-middle attacks, and verify that
   the peer is authorised to take part in signalling at the GIST layer.
   The authorisation check is carried out by comparing the presented
   identity with each Authorised Peer Database (APD) entry in turn, as
   discussed in Section 4.4.2.  This section defines the identity
   comparison algorithm for a single APD entry.

   For TLS authentication with X.509 certificates, an identity from the
   DNS namespace MUST be checked against each subjectAltName extension
   of type dNSName present in the certificate.  If no such extension is
   present, then the identity MUST be compared to the (most specific)
   Common Name in the Subject field of the certificate.  When matching
   DNS names against dNSName or Common Name fields, matching is case-
   insensitive.  Also, a "*" wildcard character MAY be used as the left-
   most name component in the certificate or identity in the APD.  For
   example, *.example.com in the APD would match certificates for
   a.example.com, foo.example.com, *.example.com, etc., but would not
   match example.com.  Similarly, a certificate for *.example.com would
   be valid for APD identities of a.example.com, foo.example.com,
   *.example.com, etc., but not example.com.

   Additionally, a node MUST verify the binding between the identity of
   the peer to which it connects and the public key presented by that
   peer.  Nodes SHOULD implement the algorithm in Section 6 of [PKIX]
   for general certificate validation, but MAY supplement that algorithm
   with other validation methods that achieve equivalent levels of
   verification (such as comparing the server certificate against a
   local store of already-verified certificates and identity bindings).

   For TLS authentication with pre-shared keys, the identity in the
   psk_identity_hint (for the server identity, i.e. the Responding node)
   or psk_identity (for the client identity, i.e. the Querying node)
   MUST be compared to the identities in the APD.

   ######

Top      Up      ToC       Page 57 
Authors' Addresses

   Peter Saint-Andre
   Cisco
   1899 Wyknoop Street, Suite 600
   Denver, CO  80202
   USA

   Phone: +1-303-308-3282
   EMail: psaintan@cisco.com


   Jeff Hodges
   PayPal
   2211 North First Street
   San Jose, California  95131
   US

   EMail: Jeff.Hodges@PayPal.com