[Nicolas Williams <Nicolas.Williams@sun.com>] client-side pre-auth re-architecting

[Nicolas Williams]

On Mon, Dec 30, 2002 at 03:28:06PM -0500, Sam Hartman wrote:
>  - the as-reply should probably be passed, when available, to the
>    pa_function

I'd proposed this and we'd then decided against it, but I forgot about
it when I wrote my notes, then I sent you a correction.

>    [hartmans]  I remember saying this, but I thought I unsaid it
>    later.  I am reluctant to have one preauth type reading another
>    preauth type 's data.

Hmm, I thought it was I who proposed it; I didn't state why because it
immediately dawned on me that my motive for proposing it was, well,
hackish, namely that a pre-auth mech could try multiple keys against an
as-rep should it be possible that one of multiple key derivation or what
have you approaches could apply.  Hackish - so I take it back - these
things should be deterministic.

Now, what is necessary is that multiple pre-auth mechs be able to
interact to produce the as-rep decryption key, and this is how I think
it should be done:

 - first, pre-auth order matters

 - second, the pa_functions should all get the same (krb5_keyblock *)
   argument for each krb5_gic() call, so that each pa_function can
   inspect the keyblock produced by the preceding pa_functions (if any)
   and modify it if need be; the (krb5_keyblock *) parameter being an
   accumulator of sorts.

I remember sometime around the interim mtg last February I proposed
mixing PA-TGS-REQ with PA-ENC-TIMESTAMP in a single AS exchange as a way
of accomplishing DCE RFC 26 style pre-auth without having to define any
new ASN.1 types.  The client would include a PA-TGS-REQ using a host
principal as the client principal of the embedded AS-REQ, and a
PA-ENC-TIMESTAMP encrypted with a key derived from both, the user's long
term key and the session key of the AS-REQ in the PA-TGS-REQ - or
perhaps encrypted twice.  Thus my interest in making it possible for
pa_functions to interact.

The general principle here might be that when the pa_function for
PA-ENC-TIMESTAMP is called with a keyblock allocated it should derive
its key from that and the user's key (which comes from the get_as_key
function).  This implies a similar principle at the protocol level, and
so this part of this discussion should move to the KRB WG now, but even
if no pre-auth interactions are specified, IMO the client-side pre-auth
infrastructure should make it possible to implement interacting
pre-auth mechs.

Cheers,

Nico
--