ietf
[Top] [All Lists]

Re: Review of draft-saintandre-tls-server-id-check

2010-09-08 17:01:46
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" <stefan(_at_)aaa-sec(_dot_)com> 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" <stefan(_at_)aaa-sec(_dot_)com> 
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" <bernard_aboba(_at_)hotmail(_dot_)com> 
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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>