OTP: Putting the nonce in the cookie

[Linus Nordberg]

Hi list,

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.

We'll definitely have to think more about how the nonce should be
constructed.  As mentioned in kdc_preauth_get_cookie():

     If cookies are used for real, versioning so that KDCs
     can be upgraded, keying, expiration and many other issues need
     to be considered.              

[0]
http://git.nordu.net/?p=krb-otp.git;a=commit;h=c8ca1a83805ce967bcf251ff55...

Thanks,
Linus

[Sumit Bose]

On Tue, May 17, 2011 at 12:15:34PM +0200, Linus Nordberg wrote:
>  Hi list,
>  
>  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.

bye,
Sumit

>  
>  We'll definitely have to think more about how the nonce should be
>  constructed.  As mentioned in kdc_preauth_get_cookie():
>  
>       If cookies are used for real, versioning so that KDCs
>       can be upgraded, keying, expiration and many other issues need
>       to be considered.              
>  
>  [0]
> http://git.nordu.net/?p=krb-otp.git;a=commit;h=c8ca1a83805ce967bcf251ff55...
>  
>  Thanks,
>  Linus
>  _______________________________________________
>  authhub-devel mailing list
>  authhub-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/authhub-devel

[Linus Nordberg]

Sumit Bose <sbose(a)redhat.com&gt; wrote
Wed, 18 May 2011 14:09:34 +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.

And we do know the order.  From RFC 6113 2.4:

   From the standpoint of evaluating the pre-authentication, the KDC
   first starts by initializing the pre-authentication state.  If a PA-
   FX-COOKIE pre-authentication data item is present, it is processed
   first; see Section 5.2 for a definition.

[Sumit Bose]

On Wed, May 18, 2011 at 11:34:14PM +0200, Linus Nordberg wrote:
>  Sumit Bose <sbose(a)redhat.com&gt; wrote
>  Wed, 18 May 2011 14:09:34 +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.

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.

Btw. I think it would be better to say 

if (cookie && cookie->length) {

instead of 

if (cookie->length) {

because if there are still preauth methods left after you set 'cookie =
NULL' cookie->length will segfault.

bye,
Sumit

>  
>  And we do know the order.  From RFC 6113 2.4:
>  
>     From the standpoint of evaluating the pre-authentication, the KDC
>     first starts by initializing the pre-authentication state.  If a PA-
>     FX-COOKIE pre-authentication data item is present, it is processed
>     first; see Section 5.2 for a definition.
>  _______________________________________________
>  authhub-devel mailing list
>  authhub-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/authhub-devel

[Linus Nordberg]

Sumit Bose <sbose(a)redhat.com&gt; 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.