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

[Nicolas Williams]

On Mon, Dec 30, 2002 at 05:56:58PM -0500, Sam Hartman wrote:
> >>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:
> 
>     >> - the as-reply should probably be passed, when available, to
>     >> the pa_function
>     >> 
>     >> [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.
> 
>     Ken> Hm, I can think of cases where it would be useful, actually
>     Ken> (a preauth type that might have different behavior if you
>     Ken> were doing hardware preauth, for example).
> 
> Which is exactly why I think it should not exist.  It might get used.

I think Ken is talking about passing all the pa-data to the
pa_functions, and I while agree that that is a far cleaner thing to do
than passing the entire as_reply to the pa_functions I don't think it
should be necessary for two reasons: a) because the pre-auth mechs that
need this can use their contexts to share the data they need, if they
need to share more than the as reply keyblock, and b) because, IMO
multi-pre-auth AS exchanges should be generally possible, not just in a
few pre-ordained combinations, at least with respect to PA-ENC-TIMESTAMP
(see my previous post today in this thread).

What the pa_functions need to share is the as-rep decryption keyblock.

And perhaps there should be a way to get the default as reply decryption
key at most once per-gic call through the gak function, thence have it
stored (memoized) in the gic context, where it can be modified if
necessary by the pa_functions, but which would still be separate from
the end result as-reply decryption keyblock.  But I don't think even
this is needed; just sharing the end result keyblock will do for general
case I propose of modifying the PA-ENC-TIMESTAMP key (and therefore the
AS reply decryption key) with the keyblock from preceding pre-auth mechs
in the same AS message.

> Instead, the hw auth preauth should store something in the context.

Yes.

> Of course that means that the working group needs to discuss preauth
> ordering issues.

Yes!  Pre-auth order must matter in multi-preauth KDC exchanges, though
it isn't clear that this is the the crucial thing to decide at the WG
(it's obvious) - the crucial thing will be key derivation by pre-auths
using key material from preceding pre-auths in the same exchange; it
will be most helpful to restrict multi-preauth scenarios such that all
of them use the same enctypes.

Nico
--