FW: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Forwarding this also to the pkix WG for those who don't follow the
Kerberos list.

/Stefan
 

-----Original Message-----
From: Stefan Santesson 
Sent: den 24 maj 2005 09:37
To: 'Sam Hartman'
Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@xxxxxxx
Subject: RE: Required binding method - Was RE: PKINIT-26 changes:
identifying the kdc certificates

Sam,

Reading your reply actually makes me think that we are in agreement.

I agree that it is impossible to bind to a SRV record unless a symbolic
name has been defined and the security considerations assigned to that
definition should always be followed.

However, I can't see that you need to do more than that.
Once the symbolic name has been defined and it is used according to it's
definition and security considerations to discover services, then I
can't se any negative security effects from binding that SRV RR name to
a public key certificate to enable authentication of the host's
authorization to deliver that service.

In summary I don't think it is reasonable for a standard defining an
otherName for a SRV RR to explicitly define what services it can be used
with. But I would agree to describe the principles in the security
considerations.


/Stefan
 

> -----Original Message-----
> From: Sam Hartman [mailto:hartmans-ietf@xxxxxxx]
> Sent: den 23 maj 2005 20:03
> To: Stefan Santesson
> Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@xxxxxxx
> Subject: Re: Required binding method - Was RE: PKINIT-26 changes:
> identifying the kdc certificates
> 
> >>>>> "Stefan" == Stefan Santesson <stefans@xxxxxxxxxxxxx> writes:
> 
>     Stefan> Sam,
> 
>     >> I hope the PKIX working group does not approve a version of the
>     >> SRV OtherName that would allow it to be used with an
>     >> application without some standard enabling such usage.  So I
>     >> would expect some document to explicitly mention that it can be
>     >> used with pkinit.  But I agree that if PKIX were to approve an
>     >> overly broad standard, the current text would allow it to be
>     >> used.
>     >>
>     >>
> 
>     Stefan> [Stefan] I don't think you can constrain its usage in a
>     Stefan> PKIX RFC or force some RFC to enable it for each service
>     Stefan> type.
> 
>     Stefan> RFC 2782 already makes it possible to bind to a service
>     Stefan> only based on service name, protocol and domain. There are
>     Stefan> no limitations to that.
> 
> 
> Please See the following text  from RFC 2782:
> 
> 
>   Applicability Statement
> 
>      In general, it is expected that SRV records will be used by
clients
>         for applications where the relevant protocol specification
> indicates
>            that clients should use the SRV record. Such specification
MUST
>               define the symbolic name to be used in the Service field
of
> the SRV
>                  record as described below. It also MUST include
security
>                     considerations. Service SRV records SHOULD NOT be
used
> in the absence
>                        of such specification.
> 
> 
> 
> So your proposal clearly should not be used for applications that do
> not use SRV records in the first place.  Some applications that use
> SRV records (most of the IMPP protocols fall into this examlpe)
> already specify how certificates should be bound to these
> applications.  It is undesirable to have two methods of doing the same
> certificate binding without compelling reason to do so.Failing this
> would lead to decreased interoperability.  From this I conclude that
> your name type should only be used when explicitly specified.  Things
> are of course more fuzzy for applications that do not have formal
> published specifications.