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

["Stefan Santesson" <[e-mail]>]

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
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: den 23 maj 2005 20:11
> To: Stefan Santesson
> Cc: Sam Hartman; [e-mail]
> Subject: RE: Request for new work item - Defining an SRV RR otherName
> 
>         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
> 
> 
>