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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stefan Santesson
Nico,

I understand.

My postings had nothing to do with whether PKINIT need to have one
REQUIRED method or not. I was just assuming that the logic from draft 25
was acceptable to the group.

But it would certainly be interesting to know why you feel that one
common method must be REQUIRED. Many other security protocols allow
implementation of arbitrary trust decisions.

Say for example that this group selects checking of a Kerberos principal
name in the KDC certificate as a REQUIRED method. Say also that I have
an implementation where the host name of the KDC is known to all my
clients and the KDC has a trusted certificate which certifies that host
name but NOT the principal name. Why would conformant clients need to
reject that certificate?

What do you suggest should be the REQUIRED method?

/Stefan


> -----Original Message-----
> From: [hidden email] [mailto:owner-ietf-krb-
> [hidden email]] On Behalf Of Nicolas Williams
> Sent: den 23 maj 2005 10:27
> To: Stefan Santesson
> Cc: Liqiang(Larry) Zhu; Sam Hartman; [hidden email]
> Subject: Re: PKINIT-26 changes: identifying the kdc certificates
>
> On Mon, May 23, 2005 at 06:22:05PM +0100, Stefan Santesson wrote:
> > Nico
> >
> > There seems to be a misunderstanding here.
> >
> > You say:
> > > There must be at least one REQUIRED, practical method.
> >
> > But Larry just explained that the previous drafts currently say:
> > "Unless the client can otherwise prove that the public key used to
> > verify the KDC's signature is bound to the target KDC"
> >
> > Which means that there is currently NO REQUIRED method.
>
> This is one reason that PKINIT is still an Internet-Draft.  I can't
see
> how it would progress if this is not addressed.
>
> What the I-D says at this moment has no force.
>
> > If you want to propose a required method, then I agree that it
should
> > not be SRV RR.
>
> We must have one REQUIRED method -- otherwise PKINIT will not
progress.
>
> > If there is NO required method, then SRV RR need not to be mentioned
> > (just implicitly allowed).
>
> Sure, but it would be a serious misunderstanding of IETF process to
> think that no method might be REQUIRED yet have the document progress
to
> Proposed Standard.  Not gonna happen.
>
> Cheers,
>
> Nico
> --
>



Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
>>>>> "Stefan" == Stefan Santesson <[hidden email]> writes:

    Stefan> Nico, I understand.

    Stefan> My postings had nothing to do with whether PKINIT need to
    Stefan> have one REQUIRED method or not. I was just assuming that
    Stefan> the logic from draft 25 was acceptable to the group.

You changed a MUST to a MAY in such a way that you changed the logic.

I agree with Larry that the current text is fine.

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.



Reply | Threaded
Open this post in threaded view
|

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

Stefan Santesson
In reply to this post by Stefan Santesson

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] I don't think you can constrain its usage in a PKIX RFC or
force some RFC to enable it for each service type.

RFC 2782 already makes it possible to bind to a service only based on
service name, protocol and domain. There are no limitations to that.

And in this case the only thing the client knows about the service is
its SRV RR. Every other knowledge is obtained from the DNS server or
learned through using the service.

So, if the client wants to validate that the host it accesses is a
legitimate provider of the requested service then asserting the SRV RR
in the server certificate can only increase security of a binding that
already is allowed and already takes place in an insecure manner.





Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
>>>>> "Stefan" == Stefan Santesson <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Stefan Santesson
In reply to this post by Stefan Santesson
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:[hidden email]]
> Sent: den 23 maj 2005 20:03
> To: Stefan Santesson
> Cc: Nicolas Williams; Liqiang(Larry) Zhu; [hidden email]
> Subject: Re: Required binding method - Was RE: PKINIT-26 changes:
> identifying the kdc certificates
>
> >>>>> "Stefan" == Stefan Santesson <[hidden email]> 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.