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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 16:01:16 -0600

On 9/8/10 11:28 AM, Stefan Santesson wrote:
> For clarity, I'll provide two examples where I think it is motivated to
> obtain the FQDN reference identifier in an automated fashion and not through
> direct user input or configuration (contrary to section 5.1).

Thanks for the examples.

> 1) Obtaining EU Trusted Lists
> EU has standardized on XML based lists over national Trust Service Providers
> and their certificates. Each country in the EU publish their own list.
> The EU commission provides a central list with all the URLs to each national
> list.
> 
> The first step is for the client to establish a secure connection with the
> EU commission and download the EU list. This is done by configuration.
> 
> The second step is to automatically obtain reference identifiers for all
> national lists from the EU list.
> 
> 
> 2) Redirects from a trusted service.
> If I connect to a trusted service and then get redirected to another host,
> it can be reasonable to obtain the reference identifier from the rediricet.
> Typical application I can think of is a redirect to a SAML IdP or a SAML
> Discovery service.

It seems to me that in both of these cases, the user has placed trust in
a certain entity (the EU's system of trust service providers, a
particular trusted service) and has configured his or her application
client to allow that entity to transform a source domain into a
target-domain-based reference identifier for the purposes of secure
connection. (One could argue that DNSSEC might result in a similar
arrangement.)

Would the following text address the scenarios you mention?

###

5.1.  Service Delegation

   When the connecting application is an interactive client, the source
   domain name and service type SHOULD 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 SHOULD 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.

   There are several scenarios in which it can be legitimate for an
   interactive client to override the recommendation in the foregoing
   rule.  Examples include:

   1.  A human user has explicitly configured the client to associate a
       particular target domain with a given source domain (e.g., for
       connection and identity checking purposes the user has explicitly
       approved "apps.example.net" as the target domain associated with
       a source domain of "example.com").

   2.  A human user has explicitly agreed to trust a service that
       provides mappings of source domains to target domains, such as a
       dedicated discovery service or an identity service that securely
       redirects requests from the source domain to a target domain
       (however, such an arrangement is not encouraged and if a client
       supports such a service then it needs to disable it by default
       and carefully warn the user about the possible negative
       consequences of trusting such a service).

###

I'm quite leery of these identity mapping services you have mentioned; I
can see that some people might trust them, but I think we need to
encourage clients to clearly and forcefully warn users about them,
because trusting such a service means handing over a great deal of power.

/psa

> /Stefan
> 
> 
> On 10-09-08 4:21 PM, "Stefan Santesson" <[email-masked]> wrote:
> 
>> 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
>>>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 00:59:29 +0200

Peter,

I don't see the problem with accepting a host names provided by DNS SRV
record as the reference identity.

Could you elaborate the threat?

Example:

I ask the DNS for the host providing smtp services for example.com
I get back that the following hosts are available

smtp1.example.com, and;
smtp2.example.com

I contact the first one using a TSL connection and receives a server
certificate with the SRVName _smtp.example.com and the dNSName
smtp1.example.com

The certificate confirms that the host in fact is smtp1.example.com and that
it is authorized to provide smtp services for the domain example.com.

That is all you need. The host name from the DNS server was setting you on
the track but is not considered trusted. What you trust is the names in the
certificate.

As to IdP services. This type of redirect is extremely common and widely
deployed in SAML. 

Example: The client connects to a service by choice. That service is
retrieving the metadata for the identity federation from a central database.
Among other things this metadata contains URLs to all approved Identity
provides (IdP) in the federation.

In order to allow the user to select the appropriate IdP service the user
may first be directed to a SAML discovery service (often called WAYF =
"Where Are You From"). The WAYF service redirects the user back to the
original service with information about the selected IdP. The Service
locates the IdP from the metadata and redirects the user to its IdP for
identification. The user is then handed a ticket (SAML assertion) and gets
redirected back to the service with the ticket.

Again, this is very common and designed and has undergone thorough security
reviews in a very large community.

I think it is very bold of the IETF to claim that SAML got it wrong and
should not be allowed.

Unfortunately, for these reasons I still don't think the proposed text is
satisfactory

/Stefan

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Sep 2010 14:11:37 -0400

> the track but is not considered trusted. What you trust is the names in the

This is a more complicated example than the current draft
addresses.

In your example, the client is verifying "a combination of 
identifiers" (SRVName and dNSName) in the certificate. This
seems like a reasonable thing to do, but this is not what
most clients do today (I'd be happy to be corrected about
that). Typically, they consider a match successful once they've
found a single acceptable reference identifier. In that case,
you can't simply use a reference identifier that contains
a DNS mapped identifier unless you've obtained it an authenticated
(or statically configured) manner.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 21:29:53 +0200

On the issue of checking multiple name forms.

I would put it in another way. Web clients are typically only used to check
the domain name and nothing else because it is the only thing they care
about and know how to match.

PKI enabled clients in general are used to check numerous of name forms and
attributes in order to determine a match.

When you add SRV-ID to the pool you change what is usual in the case of TLS.

I think it is wrong to say as a general rule that a certificate successfully
maps to the appropriate server if either the SRV-Name or the DNS Name
matches. To me this is highly context dependent where different protocols
and applications have different needs.

If the only thing I need to know is that the server is authorized to deliver
the requested service for the requested domain, then SRVName match only is
OK. If you need to know that this host is the host it claims to be, then
it's not.

What needs to be checked is to me a typical case of local policy and one
size does not fit all.

/Stefan

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Sep 2010 16:08:33 -0400

> about and know how to match.

Not just Web, but likely the various other applications listed 
in the appendix of draft-saintandre-tls-server-id-check also
(IMAP, POP3, LDAP, ..)

> attributes in order to determine a match.

Can you give us some examples of such applications, and where 
their subject identity matching rules are specified? Appendix
A ("Prior Art") probably should consider them.

> and applications have different needs.

Yeah, I think I agree with that. Ultimately the application protocol
should decide what its (potentially arbitrarily complex) identity
matching rules should be. This is why I'm suspicious that the current
draft can successfully achieve it's supposed goal of defining some
general purpose rules or best practices.

One of the ideas was that application protocol designers often
don't want to be concerned with the complex details of certificate
matching and verification rules and would like to refer to some 
standard document that does.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 22:55:08 +0200

Shumon,

> A ("Prior Art") probably should consider them.

Right now I have none that is applicable to the listed protocols. So I don't
think I have an example that is suitable for this annex.
But in general many government services using PKI are comparing multiple
attributes. Many national PKIs in Europe have banned single identifiers in
their certs, so the applications are forced to do multiple attribute
comparisons.

The thing is that name comparison is often done on an application level
according to local policy and even on the user level and the only thing I
have learned after spending 18 years with PKI is to expect almost anything
:)

In this context, EKUs are often also an important part of certificate
acceptance. A dimension that I miss in the current spec.

I don't think it is particularly useful to specify in generic documents what
constitutes a positive identification of the subject in terms or required
matching name forms.
It becomes useful mostly only when you want to achieve interoperability
within a reasonably narrow context.

/Stefan