Subject: RE: SRV SAN applicability statement - Was RE: Requested changes to SRV SAN

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Apr 2007 18:38:23 +0100

The discussion about SRVSAN applicability statement is stuck. And I would like to unstuck it.

Do you think it is reasonable for an alt name RFC to state that the name MUST not be used in any protocol unless specifically allowed?
Please see my e-mail below for an example where I think it would be unreasonable to make such restriction.

If such restriction would be imposed, how should it be formulated?
I personally don't think it can be reasonably formulated.

When we have this issue sorted, I will go ahead and post an updated draft.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Stefan Santesson
> Sent: den 23 mars 2007 01:18
> To: 'Sam Hartman'; Michael Myers
> Cc: [email-masked]; Stephen Kent; Tim Polk; 'Russ Housley'
> Subject: SRV SAN applicability statement - Was RE: Requested changes to
> SRV SAN
>
> After some discussions face to face, it is clear to me that I have not
> been successful in explaining my point.
>
> From what I have understood, Sam wants us to do is to say something
> like the following:
> The srv subjectAltName name form MUST NOT be used to validate the
> identity of any entity unless the protocol within which the
> identification is done explicitly specifies and permits the use of this
> name form.
>
> Sam has told me that it would not be sufficient to require the use of
> SRV SAN to be consistent with the protocol. It MUST be explicitly
> allowed.
>
>
> The rest of this mail intends to explain why this is unreasonable and
> doesn't work.
> I will first explain the general use case and then make an explicit
> example.
>
> General use case
>
> 1) Client seek a service based on service name and domain.
> 2) Client makes a query to the DNS server and receives a list of
> suitable host names and their address.
> 3) The Client contact one of the hosts suggested by DNS
> 4) The client receive the certificate of that host
> 5) The client verifies the identity of the host and determine if this
> is a valid host for the requested service.
>
> Note that the information from the certificate is NOT used to construct
> any DNS query. It is only used to validate the service host.
> Note also that for this to happen at all, the service type asked for
> MUST be supported by the DNS or you would not reach beyond step 2. So
> for us to even consider the certificate in this case, we have an
> automatic guarantee that at least the DNS supports this service name as
> basis for host lookup. Thus it should already have passed the
> applicability statement of RFC 2782.
>
>
> Lets now take a specific case.
>
> 1) Client seeks the LDAP server of example.com
> 2) Client makes a dns query for _ldap._tcp.example.com
> 3a) Client receives the following list of suitable hosts:
> ldap1.example.com and ldap2.example.com
> 3b) Client contact ldap://ldap1.example.com and initiates a TLS session
> according to RFC 4513
> 4) Client receives the server certificate from the TLS initialization.
> 5) Client verifies the server certificate according to RFC 4513.
>
> Now. This server certificate has a subject DN with a number of
> attributes that does not mean anything to the client.
> The server certificate contains the dnsName SAN with the value
> ldap1.example.com
> The server certificate contains a SRV SAN otherName with the value
> _ldap.example.com
>
> Through the dnsName SAN, the client will be assured that it is in fact
> talking to the host ldap1.example.com. But unless the client can fully
> trust the DNS, the client still don't know if this host is authorized
> to provide the ldap service for this domain. If the DNS was spoofed,
> the client could be talking to the wrong server.
>
> But, here the CA has also bound the key to the srv name
> (_ldap.example.com). Through this name the client has an assertion from
> the CA that this host is actually an authorized ldap server for the
> example.com domain.
>
> Must the client disregard from this information. YES according to Sam
> (If I understand him right).
>
> Because RFC 4513 does not explicitly mention and approve use of the SRV
> SAN name form (And how could it, this name form is not an RFC yet)
>
> RFC 4513 states:
>
> 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.
>
>
> This text is 100% consistent with using srv san otherName even though
> it is not explicitly mentioned.
>
> So we have a case where use of DNS lookup for a service type that
> established and supported by DNS servers as well as having an IANA
> registered service name. We have a security protocol that provides
> freedom for clients to define what a "reference identity" is. Yet we
> would not be allowed to use the only name in the certificate that gives
> the client what it needs to verify the host.
>
> That does not make any sense to me at all.
>
> Why is it necessary to update RFC 4513 to make it legal to use this
> name form when its use is already consistent with the standard?
> What if I have a privately defined SAN otherName, can I use that? I
> think RFC 4513 clearly allows that.
> What if that privately defined otherName contains exactly the same info
> as our SRV SAN, can I use it?
>
> Please clarify if I have understood you wrong Sam.
>
>
>
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
>
> > -----Original Message-----
> > From: Sam Hartman [mailto:[email-masked]]
> > Sent: den 22 mars 2007 09:46
> > To: Michael Myers
> > Cc: Stefan Santesson; [email-masked]; Stephen Kent; Tim Polk
> > Subject: Re: Requested changes to SRV SAN
> >
> > >>>>> "Michael" == Michael Myers <[email-masked]> writes:
> >
> >     >> Sam Hartman has a discuss requiring this document to say that
> >     >> this name form MUST NOT be used unless explicitly allowed by
> >     >> the protocol being used.
> >
> >     Michael> Because . . . ?
> >
> > Two reasons.  first, the SRV DNS RR definition has a very strong
> > applicability statement.  SRV records cannot be used except when a
> > protocol specifically defines their use.  This increases
> > interoperability.  You don't want some domains using MX to find mail
> > servers and others using _smtp._tcp.domain SRV records.  We should be
> > consistent with the SRV spec wehn definining name types for use with
> > those records.
> >
> > Second, the underlying interoperability concerns for this name type
> > apply the are the same as for SRV records.  We've had enough trouble
> > with interoperability concerns caused by CN and email address in the
> > subject name vs subjectAltName choices.  We don't want to introduce
> > other situations where there are multiple ways of naming the same
> > entity without need to do so.
> >
> > --Sam

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 27 Apr 2007 09:21:13 -0800

Stefan,

I will give this some thought and respond if I come up with something
useful.  Until then, I can say immediately that I do not favor negative
requirements.  They cannot be tested.

Mike

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Friday, April 27, 2007 9:38 AM
To: Stefan Santesson; Sam Hartman; Michael Myers
Cc: [email-masked]; Stephen Kent; Tim Polk; Russ Housley
Subject: RE: SRV SAN applicability statement - Was RE: Requested changes
to SRV SAN

The discussion about SRVSAN applicability statement is stuck. And I would
like to unstuck it.

Do you think it is reasonable for an alt name RFC to state that the name
MUST not be used in any protocol unless specifically allowed?
Please see my e-mail below for an example where I think it would be
unreasonable to make such restriction.

Stefan Santesson
Senior Program Manager

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Apr 2007 04:17:03 -0400

Hi.

I'd like to apologize for not getting back to this sooner and for
(now) putting it off yet again.  I'm about to get onto a plane to an
IESG retreat.  I'll try to deal with this over the next couple of days
although I do have a few things ahead of it.  I'll definitely discuss
with Tim.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Apr 2007 15:01:57 +0100

Thank you Sam.

I'm looking forward to your reply.

Stefan Santesson
Senior Program Manager

> Sent: den 30 april 2007 10:17
> To: Stefan Santesson
> Cc: Michael Myers; [email-masked]; Stephen Kent; Tim Polk; Russ
> Housley
> Subject: Re: SRV SAN applicability statement - Was RE: Requested
> changes to SRV SAN
>
> Hi.
>