Subject: Request for new work item - Defining an SRV RR otherName

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 18 May 2005 22:49:32 +0100

All,

I have just submitted a new personal draft under the name:
draft-santesson-pkix-srvrr-00 and I hope this draft will be available
from the IETF server soon.

With this mail, I request this WG to consider acceptance of this draft
as a PKIX work item.

The purpose of this draft is to facilitate inclusion of a service name
to a X.509 certificate subject in the form of a DNS Service Resource
Record (SRV RR).

The primary immediate need for this draft is to resolve some of the last
hard issues with Kerberos PKINIT which still lack a way to express that
a certificate is issued to a host which act as a kdc server.

The PKINIT draft suggested recently that a SRV RR (_kdc._tcp.realm)
could be placed in a dNSName in SubjectAltName extension, but this would
be incompatible with RFC 3280 definition of dNSName and would cause
issues with name constraints. To fill this void, implementation of
PKINIT will strongly benefit from the definition of a new otherName to
express SRV RR in X.509 certificates.

Since the use of SRV RR is a generic feature, not only relevant to
Kerberos, the proposal is to define this otherName in PKIX.

Below is the introduction and otherName definition pasted from the
submitted draft.

1.  Introduction

   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.

   Current defined dNSName GeneralName name forms only provide for DNS
   host names to be expressed in "preferred name syntax," as specified
   by RFC 1034 [N4]. This definition is not broad enough to allow
   expression of a SRV RR. To accommodate expression of a SRV RR in
   X.509 certificates this document therefore defines an otherName for
   SRV RR.

   As DNS query based on an SRV RR returns the name of the host
   currently available for the requested service, reasonable subsequent
   authentication of that host as the appropriate host for the service
   will require the host to demonstrate that it is an authorized to
   provide the requested service.

   The ability to associate a host with a SRV RR in an X.509 certificate
   therefore facilitates the binding of the host to the originally
   requested SRV RR in order to protect against DNS spoofing attacks
   where an altered DNS could return the host name of a rouge or hacked
   host.

   One example where expression of a SRV RR can be very useful is to
   identify a host as a legitimate Kerberos KDC server.

2.  SRV RR otherName

   This section defines the SRVRRName as a form of otherName from the
   GeneralName structure in SubjectAltName.

   The SRVRRName if present MUST contain a Service Resource Record (SRV
   RR) formed according to RFC 2782 [N3].

   The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as
   follows:

      id-on-sRVRRName   OBJECT IDENTIFIER ::= { id-on ? }

      SRVRRName ::= IA5String

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 20 May 2005 18:28:08 +0100

Yes,

The initial background thought was that more demanding encodings would
be more of an issue for host labels rather than service resource records
and thus IA5String would be sufficient, but I agree at this point to the
suggestions to specify UTF8String instead.

Stefan Santesson

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Jean-Marc Desperrier
> Sent: den 20 maj 2005 01:42
> To: [email-masked]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> Manger, James H wrote:
> 
> >How about using UTF8String, instead of IA5String?  The latter does
not
> gain much (it can still include chars such as 0x00, newline, bell that
are
> presumably not valid in SRV RR names), while the former should be more
> future-proof.
> >
> >      SRVRRName ::= UTF8String
> >
> >
> 
> >Could you post the suggestion to the pkix list to see if there are
any
> >other reactions?
> >
> >
> It's already really a pity that dNSName forces us to store SAN in ACE
> encoding, instead of being able to put the real unicode value, so I'm
> all for not doing the mistake again.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 May 2005 15:39:14 -0400

Hi.  I'm speaking as an individual not as an AD.

This proposal was originally introduced as a use of dnsname in the
Kerberos working group for pkinit.

The authors of the proposal would like to name services as they are
identified by users.  For example a user types foo.bar.example.com
into some program.  The program looks up a SRV record for some service
and then connects to that service.  If insecure DNS is used then the
dns lookup should not be part of the name against which a certificate
is checkde.

We're seeing a similar situation in the kitten working group ; see
draft-ietf-kitten-gssapi-domain-based-names-00.txt.

The idea of this proposal is that the certificate contain the name
that the client system would look up in the same form as the client
uses to look in DNS.

I'm not sure how this proposal has evolved since it was first
presented to me.  Originally the goal was so that application
libraries could use some sort of automatic mechanism to:

* Look up SRV records

* Bind to TLS certificates

* Find the Kerberos principal name

* Bind to pkinit certificates.

All the application author would do would be to pass the service
protocol and name into some magic function.

That bothers me.  There is no guarantee that the SRV record tag will
match the GSS/Kerberos principal name.  There is no guarantee that the
service in question doesn't have some better choice for certificate
binding like one of the IMPP-specific solutions.

I'm also not quite sure that SRV tags are real/really the right thing
to be binding to.

If the PKIX working group does adopt this proposal I would recommend
being very careful.  Make sure to scope it only to be used for
applications/services where it is appropriate.  Make sure to discuss
applications that already have a mechanism for binding their
certificates.

It might also be important to find out if there is actually a use case
for this name type before standardizing it.  There wasn't really that
much support in krb-wg for the earlier version of this.

--Sam

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 21 May 2005 06:07:16 +0100

Sorry for being a bit unclear.
Yes, you could use the Kerberos principal name specifically for Kerberos
but not for other service types.

The benefit from the proposed SRV RR other name is that you could deploy
a generic approach, which maps 1:1 to service lookup via DNS for a wider
range of services and avoid different solutions for each service type.

Yes, this means that we need to go through the pain to recognize a new
otherName, but now when we have to go there, the thought is that we then
may be better served with a more generic approach for client side
service validation rather than doing it just for Kerberos. 

/Stefan

> From: Sam Hartman [mailto:[email-masked]]
> Sent: den 20 maj 2005 19:10
> To: Stefan Santesson
> Cc: [email-masked]
> >>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:
> 
>     Stefan> Sam, My recollection of this issue is a bit different from
>     Stefan> yours.
> 
>     Stefan> The central need here is to enable the KDC to express in a
>     Stefan> certificate the fact that it is a KDC in a way that male
>     Stefan> sense to clients.
> 
> 
> If this is all you want, bind the KDC certificate to the TGS principal
> for the realm. That's what Larry's pkinit 26 text does.
> 
> The original problem with that solution is that it required CAs to
> implement the kerberos OtherName.  However this approach also requires
> the CA to implement a new OtherName.

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 23 May 2005 17:21:08 +0100

FYI

The SRV RR draft is now available from internet-drafts.

http://www.ietf.org/internet-drafts/draft-santesson-pkix-srvrr-00.txt

/Stefan

> On Behalf Of Stefan Santesson
> Sent: den 20 maj 2005 22:07
> To: Sam Hartman
> Cc: [email-masked]
> Subject: RE: Request for new work item - Defining an SRV RR otherName
> 
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 24 May 2005 04:59:54 +0100

Yes,

The intention was actually primary to include the lookup key.

Yes there are some clarifications needed in this aspect but I waited
with trying to formulate the limitations until we have got a bit further
towards accepting the work item.

Thanks for noticing the issue.

Stefan Santesson

> From: Tom Gindin [mailto:[email-masked]]
> Sent: den 23 maj 2005 20:11
> To: Stefan Santesson
> Cc: Sam Hartman; [email-masked]
>         Stefan:
>         Maybe I'm being a bit thick here, but do you really intend to
> include the entire RR contents, including the weight, target and port,
in
> this otherName?  Or do you intend to include only the lookup key
> (_service._protocol.DNSName) instead?  Some of your wording makes IMHO
> more sense in that case, and the assertion you're conveying is "the CA
> issuer has authorized this entity to provide this service for this
> domain".
>         Whatever may be the case for Kerberos, I don't see why this
> feature is problematic for (say) LDAP, except insofar as it's an
argument
> for name constraints.  I do think that you'd need to state that the
use of
> this field in a certificate is governed by DNSName name constraints.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Stefan Santesson" <[email-masked]>
> Sent by: [email-masked]
> 05/20/2005 06:44 PM
> 
>         To:     "Sam Hartman" <[email-masked]>,
<[email-masked]>
>         cc:
>         Subject:        RE: Request for new work item - Defining an
SRV RR
> otherName

> Sam,
> 
> My recollection of this issue is a bit different from yours.
> 
> The central need here is to enable the KDC to express in a certificate
> the fact that it is a KDC in a way that male sense to clients.
> 
> In a traditional Kerberos environment the KDC can be known as a KDC
> since it can demonstrate knowledge of the user's key.
> 
> In PKI initiated Kerberos, this property is lost.
> 
> If the client knows the host name, IP address or any other identity of
> the KDC, which can be mapped to information in the KDC certificate,
then
> we are good and appropriate binding is possible.
> 
> However, from what I have learned, we may face situations where a
client
> only know the name of the domain it wants to access and the fact that
it
> looks for a PKINIT enabled KDC. In this case it is assumed that the
> client would do a SRV RR query to the DNS to get the host name of the
> currently available KDC.
> 
> If the SRV RR is NOT the appropriate name to bind to in this case,
then
> my question is what the alternative is.
> 
> 
> Finally, the reason to do this in PKIX is since this in principle is a
> generic way of service discovery that may be useful also for other
> services where the client only know service name, protocol and domain.
I
> have indications that it is becoming more and more interesting to
> dynamically search for services in this manner for other services but
> I'm very interested of other opinions here.
> 
> I don't however understand in what way we need to be careful to limit
> this only to some specific services. Could you clarify this concern?
> 
> /Stefan
> 
> 
> > On Behalf Of Sam Hartman
> > Sent: den 20 maj 2005 12:39
> > To: [email-masked]