Sumit Bose <sbose(a)redhat.com> wrote
Thu, 19 May 2011 18:39:48 +0200:
| > | > I recently pushed[0] some code for putting the nonce in the PA-FX-COOKIE
| > | > (to branch otp-wip of
git://git.nordu.net/krb-otp.git). It took some
| > | > changes to generic FAST code though. Please let me know if you think
| > | > this isn't a good way of solving it. For example, I can't really
see
| > | > how this is supposed to work with authentications sets.
| > |
| > | I wonder if similar would be possilbe by adding KRB5_PADATA_FX_COOKIE to
| > | server_supported_pa_types. If this really works server_verify_preauth()
| > | should be called twice, once with the cookie and the other time with the
| > | OTP REQ data. Since we don't know in which order the data item will come
| > | we have to safe them and can check the nonce only in the second run.
| >
| > That's a clever idea. The problem with this is in the edata_proc
| > (server_get_edata() in our case) where we have to put the nonce in the
| > cookie. Without changes to get_preauth_hint_list() I can't really see
| > how we would find the cookie padata entry.
|
| I would expect that server_get_edata() is called twice too, because of
| the two pa_types. And with a bit of luck adding the "default" cookie at
| the end of the krb5_pa_data will not do any harm, because find_pa_data()
| always returns the first KRB5_PADATA_FX_COOKIE it finds. But I agree
| that this is a hack and heavily depends on the current implementation if
| the preauth logic in MIT Kerberos.
There's no cookie in the first AS-REQ so I'd expect edata_proc to be
called only once, for the PA-OTP-REQUEST. This is when we need to
generate the nonce to be put in the cookie.
| I hope authentication sets will get implemented in the near future, then
| each preauth method would be able to send an individual
| KRB5_PADATA_FX_COOKIE.
The specification isn't very clear about this.
I have not heard anything about anybody working on authentications
sets. Have you?
| Btw. I think it would be better to say
|
| if (cookie && cookie->length) {
Oh, definitely much better! :-)
Pushed, thanks.