Subject: RE: Refactoring Kerberos pre-authentication

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Thu, 11 Sep 2003 11:43:02 -0700

Sam,

A lot more than just one vendor implemented version 16 of the PKINIT draft - it is all of the device and KDC vendors that participate in the VoIP PacketCable industry project and IPCableComm (European version of PacketCable).

Sasha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 09, 2003 2:16 PM
To: [email-masked]
Subject: Refactoring Kerberos pre-authentication

Greetings.  We have several things going on with Kerberos
pre-authentication: pkinit, encrypted timestamps, the SAM draft, the
hw-auth draft, the extra-tgts draft and the anon-DH draft.  And none
of these work with each other.  That's right, the behavior for what
happens if you use more than one of these preauthentication mechanisms
at once is unspecified and in many cases there is no one obvious
correct choice.

Because of this, each preauth method ends up being responsible for all
phases of pre-authentication.  This is problematic because the authors
of each method are interested in dealing with one (or a small number)
aspect of preauthentication, but are forced to deal with all of them.
For example, the most recent version of the extra-tgt draft correctly
handles combining the reply key with the TGT session key.  but it
copies by value aspects of the encrypted timestamp draft to prove that
the user has their password.  So, if we find a better way of proving
that a user has a password, we will need to come up with a new
extra-tgt draft to use it.  We will also need a new draft to describe
how it is used outside of the context of extra-tgt.

Similarly, I've felt that the pkinit draft needed to be refactored for
several years.  I've been reluctant to bring these concerns forward
because I wasn't aware of specific problems that this refactoring
would solve and because I wasn't sure I could propose a refactoring
that was minimally disruptive and that met the group's needs.  As I've
started to compare the needs of the anon-DH draft and pkinit, I
believe I better understand what my concerns are with pkinit.

I'm going to briefly describe what I believe the existing
pre-authentication drafts do.  I'm going to try and make my
description modular--presuming for the moment that each draft provides
a number of components to some global pre-authentication architecture.
The places where I draw module boundaries are somewhat arbitrary and
are an artifact of how I have been thinking about the problems; I'd be
interested in looking at how others see the module boundaries.

I don't actually know how to construct the global pre-authentication
architecture I'm presuming exists, nor do I fully know all the
properties of this presumed architecture.  I think that if we are
willing to delay pkinit until extensions and to significantly change
the protocol messages, I could come up with such an architecture.
That would be significantly undesirable: we want to get pkinit
published before extensions, and at least one vendor has implemented
draft 16 of pkinit so we have some desire to avoid changing the
protocol more than is necessary.  So rather than making a specific
proposal I'll try to characterize what properties we'd need.
Hopefully those interested in seeing minimal changes to pkinit can
help me figure out how to get these properties within the current
document.

On to the descriptions of the modules our current preauth documents
give us:

1) The encrytped timestamp preauth in the base Kerberos spec allows us
    to verify that the party sending an as_req is the party named in
    the client principal.  This is done by proving that the party
    sending the as_req knows the key of that principal.  It doesn't do
    a good job, because the proof is sufficient for a passive attacker
    to mount an offline dictionary attack against.  Let's say this
    module is an instance of the client-authentication facility.

2) The SAM draft provides  another  instance of  the
   client-authentication facility.  If the client is able to come up
   with a response  to a challenge, the client proves that the client
   has some hardware token.  

3) The SAM draft provides an additional module that is tightly coupled
   to module #2.  The response from the hardware token can be used to
   provide strong cryptographic bits to strengthen the reply key so
   that it is not just the long-term key of the client.  Let's call
   this an instance of the strengthen-reply-key facility.  This module
   is inseparable from #2; the fact that the two are tied together is
   a consequence of what is happening, not just of the way the
   protocol is specified.

4) The extra-tgt draft provides an instance of the
   client-authentication facility that works much the same  as the one
   in the encrypte timestamp preauth.

5) The extra-tgt draft provides an instance of the
   strengthen-reply-key facility that is coupled to #4.  The reply key
   is strengthened by combining with a TGT session key.    Note that
   the coupling here seems to be an artifact of the way the document
   is written; if a mechanism existed to avoid the coupling it could
   be used.

6) The The hw-auth draft seems to be expired.  I think it provided a
   module that allowed a reply key to be completely replaced by an
   authorized host key in the case where a user didn't want to type
   their password over some link.  This was generally combined with
   the SAM draft, or at least some type of hardware token.  Let's call
   this an instance of replace-reply-key.

7) The pkinit draft provides a module that allows the user to sign
   part of a request with a signature key.  This proves the user's
   identity and is an instance of the client-authentication facility.
Users who use this module generally do not have a long-term Kerberos
   secret key and certainly do not want to use that key in the
   response.

8) The pkinit draft provides two different modules as instances of
   replace-reply-key.  The first is based on an encryption certificate
   and the second based on a DH exchange.    These mechanisms  are
   unique to Kerberos in that because the reply key is replaced, and
   because there is no encrypted content  in the request, any party
   could fabricate a response that looks valid to the client.  

9) The pkinit draft  includes a module that allows the response (or
   checksums of part of it) to be signed using a long-term certificate
   of the KDC.  This is an instance of the verify-response facility.

10)  The The anon-DH draft provides a strengthen-reply-key module
     based on a DH exchange.

		       Properties of a Solution

It seems that there are several basic facilities shared among these
preauthentication schemes.  I'd expect that a global preauthentication
architecture would provide some description of the facilities and of
how they interacted.

I don't think we'll be able to get a preauthentication framework like
the kcrypto framework.  There are enough interdependencies between the
parts of the preauth drafts that we'll never be able to draw clear
abstractions and and map the modules I've described here (or some
other decomposition) onto protocol elements.  But we may be able to
understand how the protocol elements fit into some model that gives
rules for composition and interaction.

In addition, we should avoid duplicate work both now and in the
future.  We should avoid requiring mechanisms like the extra-tgt draft
to include its own client authentication.

I think that pkinit seems to provide a majority of the components we'd
like to reuse.  I believe that the SAM draft could benefit both from
modules #8 and #9 being available.  I think that many Kerberos
requests could benefit from #9 being available; we could solve the
problem of needing a host key to verify that a KDC is not spoofed in
cases where the KDC had a public key and clients could use that key.
We should try and avoid having two different ways of doing DH, somehow
using the same protocol elements for #8 and #10.  And we should see if
we can use a conceptual model to help us restructure the document and
avoid needless conditional statements (-17 may already do most of the
document restructuring).  In short, it would be useful to find ways of
breaking out parts of pkinit so they could be used elsewhere without
changing the protocol when they are used in a pkinit context.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 11 Sep 2003 17:19:47 -0400

I believe it is probably desireable to get PKINIT 16 to a publishable
state, regardless of whether we end up with a more general framework.
If we do end up agreeing to a more general framework, we may want to
publish a revised document that is essentially the PKINIT 16 protocol
as an informational RFC.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Sep 2003 14:32:19 -0700

On Thu, Sep 11, 2003 at 05:30:21PM -0400, Sam Hartman wrote:
> >>>>> "Joel" == Joel N Weber <[email-masked]> writes:
> 
>     Joel> I believe it is probably desireable to get PKINIT 16 to a
>     Joel> publishable state, regardless of whether we end up with a
>     Joel> more general framework.  If we do end up agreeing to a more
>     Joel> general framework, we may want to publish a revised document
>     Joel> that is essentially the PKINIT 16 protocol as an
>     Joel> informational RFC.
> 
> I'm unconvinced.  Looking back at clarifications, I'm not really sure
> it was worth the effort.
> 
> I think we probably only want to publish one pkinit.

Regardless, as long as we can abstract PKINIT into "pre-auth modules" we
can still define a modular pre-auth framework.  If not we can define a
successort to PKINIT that is modularized after PKINIT progresses.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Sep 2003 17:30:21 -0400