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

[Ken Hornstein]

>I think Ken is talking about passing all the pa-data to the
>pa_functions,

Right.

>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,

My concern here is only that sharing your context to another pa_function
might require you to expose a lot more about your preauth internals that
you originally wanted to (which might be interesting for loadable
preauth mechanisms).  I guess this could be worked around, so I don't
think it's a show-stopper ... just something else to be careful about.

>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.

Definately.

--Ken