Subject: RE: srv based names

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Aug 2005 09:47:12 -0700

> So create more URI schemes.   Names of SRV RRs are not, IMO,
> good service identifiers.  URIs, in particular, URLs, are.

The way that we create new URI schemes these days is essentially to
assign an SRV or NAPTR prefix value. NAPTR was created expressly for URN
resolution.

All an SRV record is is a substitute for a protocol port assignment. It
is not something that is alien to the IETF way of designing protocols. 

What we see on the side of a bus is usually something like www.ipod.com
or even just ipod.com. It is actually becomming rare these days to see
http://www.ipod.com/ in advertising litterature.

In the original Internet architecture a domain name stood for a machine.
Today people want the domain name to be a logical access point for a
collection of services. mailto:[email-masked] and
jabber:[email-masked] are surely both references to the same person.

In the Web world we would much rather have a URN of the form
user:[email-masked] that can stand for all the uses of the address.

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 3 Aug 2005 18:26:56 +0100

I totally disagree.

I you approach a service knowing its URI, then binding to the URI is most appropriate.

If you approach a system with a specific e-mail address, then binding to the rfc822Name is probably most appropriate.

If you approach a service knowing its SRV service name then binding to that SRV name is most appropriate and functional.

All depends on context and what your prior knowledge is. There is no single name form that will always work.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Kurt D. Zeilenga
> Sent: den 3 augusti 2005 07:18
> To: Russ Housley
> Cc: [email-masked]
> Subject: Re: srv based names
> 
> 
> At 02:49 PM 8/3/2005, Russ Housley wrote:
> 
> >Thanks for following up; however, I do not think that Kurt's observation
> matters in many important contexts.  Stefan made a mistake by using a
> collection of LDAP servers as an example in his slides.
> 
> I don't view it as a mistake as most protocols which use SRV RRs
> use them similar to how LDAP does.  I would have said the same
> thing if he had used http, smtp, imap, etc..
> 
> >There are other services that do not have URLs.  As the discussion in the
> meeting showed, there are services for which we do not have URIs.
> Kerberos KDC is one important example.  KRB-WG is specifying the use of
> certificates in their PK-INIT document, and the Kerberos KDC will be the
> subject of the certificate.
> 
> I note that there are also services which don't have SRV support,
> one could take the argument that since some services don't have
> URIs and some services don't have SRV RRs specifications, we
> should introduce yet another service identifier form for use
> as alternative subject names in certificates.
> 
> We only need one general way of specify Internet services
> as alternative subject names.  I think URLs is the best
> general service identifier form available, certainly far
> more general than the DNS name of an SRV RR.
> 
> Kurt
> 
> 
> >Russ
> >
> >At 04:51 AM 8/3/2005, Love Hörnquist Åstrand wrote:
> >>I talked to Kurt Zeilenga after the meeting, and then understood what he
> >>was talking about. The uniformResourceIdentifier part of GeneralName
> (and
> >>this SubjectAltName) can be used instead of srv based names to limit
> what
> >>service the certificate is allowed to serve.
> >>
> >>Love

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 4 Aug 2005 10:49:03 +0100

Kurt,

Thank you for pointing to this relevant document.

Looking at the draft, and also the IESG log raises some concerns though.
It seems to me that the content in the dns URI and the SRV RR, even
though seems identical, is defined with different semantics and that is
also the source of concerns raised in IESG.

While the domain part of the SRV RR query string refers to the domain
where the service resides, the dns host name in the URI specifies host
name of the dns server.

The difference seems to me is that I can use the SRV RR query to ask any
locally configured DNS to resolve the location of the requested service
on the requested domain, the URI on the other hand points specifically
to the dns server which holds a specific record.

I think we should keep a close eye on the progress of the dns URI draft
but I don't see that it for now should prevent us from proceeding with
the proposed otherName definition.

Stefan Santesson

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: den 4 augusti 2005 10:25
> To: Stefan Santesson
> Cc: Russ Housley; [email-masked]
> Subject: RE: srv based names
> 
> I note that the IESG is considering:
> http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-12.txt
> 
> Given the ability to write this service identification
> information as the URL:
>         dns:///_kerberos._tcp.example.com?class=IN;type=SRV
> 
> in a certificate, why we need another way express this
> service identification information in a certificate.
> 
> Kurt
> 
> 
> At 07:56 AM 8/4/2005, Stefan Santesson wrote:
> >The mechanism of SRV RR corresponds to domain names so names are not
> >ambiguous.
> >
> >The SRV RR is interesting as a way to approach a domain searching for
> >appropriate recourses/services on that domain. That service may or
may
> >not correspond to a URI scheme, but it will always correspond to a
> >specific SRV tag (or you could not search for it).
> >
> >What do you gain by preventing me from binding to that service name
in a
> >cert?
> >> From: Kurt D. Zeilenga [mailto:[email-masked]]
> >> Sent: den 4 augusti 2005 02:18
> >> To: Stefan Santesson
> >> Cc: Russ Housley; [email-masked]
> >> Subject: RE: srv based names
> >>
> >> At 07:16 PM 8/3/2005, Stefan Santesson wrote:
> >>
> >> >Manual validation by users is hardly the target here.
> >> >It rather a way for a client application to determine that it has
> >reached
> >> a host that is authorized to deliver the service it searched for.
> >>
> >> I see no reason why uniformResourceIdentifier cannot be used
> >> for this excepting for the point that the current set of
> >> URI schemes is insufficient.
> >>
> >> I think it for more appropriate to engineer additional
> >> URI schemes where needed than to use the strings intended
> >> to be used to locate DNS SRV RR records as a more general
> >> service identifier than they were intended to be.
> >>
> >> It was noted your proposal was intended for use with
> >> Kerberos.  I find this quite problematic given that
> >> "EXAMPLE.COM" and "example.com" are two different
> >> realms but one domain.  That is, the string
> >> _kerberos._tcp.example.com is ambiguous.
> >>
> >> Consider a realm called "REALM.TLD" (picking TLD for some
> >> reason other than it being a valid TLD) operating using
> >> non DNS SRV based location services and a client attempting
> >> to verify that the server it contacted has an appropriate
> >> issued certificate.  That client is not only configured
> >> with knowledge of the CA which issued the certificate
> >> for this service, but a collection of other trusted CAs.
> >> An attacker can register REALM.TLD and then get one
> >> of the other trusted CAs to issue a certificate to a
> >> rough service.
> >>
> >> Now, it might be argued that this example is a bit
> >> contrived, however I think it illustrates a class of
> >> problems one will find using names of DNS RRs as
> >> alt subjects.
> >>
> >> >If you approach a service knowing its SRV service name then
binding
> >to
> >> that SRV name is most appropriate and functional.
> >>
> >> To know the name of the SRV RR implies knowledge of
> >> service-specific service information, such as a realm in
> >> the Kerberos case and an ability to map this
> >> information to a (purported) name of a DNS SRV RR.
> >> Just because one can map a realm to a (purported) name
> >> of a DNS SRV RR does mean it is appropriate to use the
> >> result of this mapping as a subject identifier in a
> >> certificate.  In the case of Kerberos, I think it
> >> can be argued that the (purported) name of a DNS
> >> SRV RR should not be used, or only used when the
> >> service location policy for that realm is DNS SRV.
> >> If the service location policy was to use a configured
> >> location, use of the (purported) name would be
> >> inappropriate.
> >>
> >> I argue it is far more appropriate to use the
> >> service-specific information in the subject identifier.
> >> That is, use the Kerberos realm as the subject identifier.
> >> Why wouldn't a Kerberos realm URI scheme met your needs
> >> in this case?
> >>
> >> Kurt