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

[Tom Gindin <[e-mail]>]

        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" <[e-mail]>
Sent by: [e-mail]
05/20/2005 06:44 PM
 
        To:     "Sam Hartman" <[e-mail]>, <[e-mail]>
        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


> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Sam Hartman
> Sent: den 20 maj 2005 12:39
> To: [e-mail]
> Subject: Re: Request for new work item - Defining an SRV RR otherName
> 
> 
> 
> 
> 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