Subject: Re: [xmpp] Review of draft-saintandre-tls-server-id-check

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Sep 2010 17:25:37 -0700

Peter said:

If that's the logic, I'd at the least like to see a "4985bis" spec make
> that clear, because IMHO it's not spelled out now.
>

RFC 4985 refers to authentication of service discovery in Sections 1 and 2.
Section 1 states:

"

   This document specifies a name form for inclusion in X.509

   certificates that may be used by a certificate relying party to
   verify that a particular host is authorized to provide a specific
   service within a domain.

   RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the

   location of services (SRV RR), which allows clients to ask for a
   specific service/protocol for a specific domain and get back the
   names of any available servers.

   Existing name forms in X.509 certificates support authentication of a

   host name.  This is useful when the name of the host is known by the
   client prior to authentication.

   When a server host name is discovered through DNS RR lookup query
   based on service name, the client may need to authenticate the

   server's authorization to provide the requested service in addition
   to the server's host name.

   While DNS servers may have the capacity to provide trusted
   information, there may be many other situations where the binding

   between the name of the host and the provided service needs to be
   supported by additional credentials.

   Current dNSName GeneralName Subject Alternative name form only
   provides for DNS host names to be expressed in "preferred name

   syntax", as specified by RFC 1034 [N4].  This definition is therefore
   not broad enough to allow expression of a service related to that
   domain.

"

Section 2 states:

"

   Even though this name form is based on the service resource record
   (SRV RR) definition in RFC 2782 [N3] and may be used to enhance
   subsequent authentication of DNS-based service discovery, this
   standard does not define any new conditions or requirements regarding

   use of SRV RR for service discovery or where and when such use is
   appropriate.

"

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Sep 2010 08:38:30 -0700

Here's a forwarded message from the author of RFC 4985:

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Wednesday, September 08, 2010 7:21 AM
To: Bernard Aboba; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Review of draft-saintandre-tls-server-id-check

My apology,

I just realized that the document defines "source domain" as what I thought
would be the "target domain"

   source domain:  The fully-qualified DNS domain name that a client

      expects an application service to present in the certificate.

Which makes my comments below a bit wrong.

I think it would be better to discuss this in terms of "reference
identifier" and "presented Identifier".

   presented identifier:  An identifier that is presented by a server to

      a client within the server's PKIX certificate when the client

      attempts to establish a secure connection with the server; the

      certificate can include one or more presented identifiers of

      different types.

   reference identifier:  An identifier that is used by the client for

      matching purposes when checking the presented identifiers; the

      client can attempt to match multiple reference identifiers of

      different types.

I see no problem in obtaining the reference identifier from a DNS lookup an
the comparing it with a presented identifier in the certificate.

Why would you require the reference identity to be provided by a human user?

/Stefan

On 10-09-08 3:40 PM, "Stefan Santesson" <[email-masked]> wrote:

> Being the author of RFC 4985 I agree with most of you say here.

> Comments in line;

> On 10-09-06 8:48 PM, "Bernard Aboba" <[email-masked]> wrote:

>> That was in fact my original question.

>> Section 5.1 states that the source domain and service type MUST be

>> provided by a human user, and can't be derived.  Yet in an SRV or

>> DDDS lookup, it is not the source domain that is derived, it is the

>> target domain.  Given that, it's not clear to me what types of DNS

>> resolutions are to be discouraged.

> This puzzled me as well. The domain of interest is the domain where

> the requested service is located = target domain.

>> As noted elsewhere, RFC 4985 appears to require matching of the

>> source domain/service type to the SRV-ID in the certificate.

> It is not. RFC 4985 says the following in section 2:

>       _Service.Name

> <snip>

>       Name

>          The DNS domain name of the domain where the specified service

>          is located.

>>  Such

>> a process would be consistent with a match between user inputs (the

>> source domain and service type) and the presented identifier (the

>> SRV-ID).

> Since this is not the definition of SRVName, this type of matching

> does not apply.

>>> Yet, Section 5.1 states:

>>> When the connecting application is an interactive client, the source

>>>    domain name and service type MUST be provided by a human user (e.g.

>>>    when specifying the server portion of the user's account name on the

>>>    server or when explicitly configuring the client to connect to a

>>>    particular host or URI as in [SIP-LOC]) and MUST NOT be derived from

>>>    the user inputs in an automated fashion (e.g., a host name or domain

>>>    name discovered through DNS resolution of the source domain).  This

>>>    rule is important because only a match between the user inputs (in

>>>    the form of a reference identifier) and a presented identifier

>>>    enables the client to be sure that the certificate can legitimately

>>>    be used to secure the connection.

>>>    However, an interactive client MAY provide a configuration setting

>>>    that enables a human user to explicitly specify a particular host

>>>    name or domain name (called a "target domain") to be checked for

>>>    connection purposes.

>>> [TP] what I thought was about to be raised here was a contradiction

>>> that

>>> RFC4985

>>> is all about information gotten from a DNS retrieval whereas the

>>> wording of

>>> s5.1

>>> in this I-D

>>> "the source

>>>    domain name and service type  ...  MUST NOT be derived from

>>>    the user inputs in an automated fashion (e.g., ... discovered

>>> through DNS resolution ... "

>>> would appear to exclude DNS resolution.  If DNS resolution is off

>>> limits, then

>>> RFC4985 would appear not to apply.

> RFC 4985 provides the client with a way to authenticate a host that it

> believes is authorized to provide a specific service in the target domain.

> It does not matter from where the client has obtained that

> authorization information or whether that information is trustworthy.

> A client may very well do an insecure DNS lookup to discover what host

> is providing the requested service. The client would then contact that

> host and obtained it's certificate. If the certificate is trusted and

> it's SRVName matches the information provided from the DNS server, then
everything is fine.

> The client now has assurance from the CA that this host is in fact

> authorized to provide this service.

> /Stefan