[Nicolas Williams <Nicolas.Williams@sun.com>] client-side pre-auth re-architecting
kenh at cmf.nrl.navy.mil
Tue Dec 31 14:16:00 EST 2002
>I think Ken is talking about passing all the pa-data to the
>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.
More information about the krbdev