[15718] in Kerberos_V5_Development
Re: preauth (I'm a Roomba in a 2'x2' room)
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 28 10:26:29 2010
From: Greg Hudson <ghudson@mit.edu>
To: Jeff Blaine <jblaine@kickflop.net>
In-Reply-To: <4BD7A344.4060801@kickflop.net>
Date: Wed, 28 Apr 2010 08:51:50 -0400
Message-ID: <1272459110.19726.288.camel@ray>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, 2010-04-27 at 22:53 -0400, Jeff Blaine wrote:
> I still can't make any sense of what is going on here.
> What is pa type 95? 85? Neither are mentioned in
> src/include/krb5/krb5.h. Does this make any sense to
> anyone?
I'm not sure why the values are being displayed in hex, but if you
convert back to decimal, 0x85 is 133 and 0x95 is 149.
133 is KRB5_PADATA_FX_COOKIE, which is described in
http://tools.ietf.org/html/draft-ietf-krb-wg-preauth-framework-16. It
doesn't play much of a role in any existing preauth interactions; for
now, we just send a constant string ("MIT") and the client sends it back
to the KDC on subsequent queries within a conversation.
149 is KRB5_ENCPADATA_REQ_ENC_PA_REP. Clients specify this to indicate
that they understand encrypted padata--an additional field in the ASN.1
encoding of a KDC request.
Neither of those are actual preauth mechanisms, so it's normal that
find_pa_system() wouldn't find them. (I think it would be possible to
treat 149 as an "informational" preauth system, but we don't; instead we
use krb5int_find_pa_data() to search for it inside
kdc_handle_protected_negotiation().)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
