another similar enctype issue
Will Fiveash
William.Fiveash at sun.com
Mon Oct 3 14:46:46 EDT 2005
On Sun, Oct 02, 2005 at 10:57:44PM -0500, Will Fiveash wrote:
> On Sun, Oct 02, 2005 at 10:47:17PM -0500, Will Fiveash wrote:
> >
> > 2. The KDC is then using the enctype found in the client key
> > (des-cbc-md5) which may not be a literal match to that requested in
> > the AS_REQ (des-cbc-crc). See return_etype_info2(). This appears to
> > be a bug as the client code is doing a literal comparion of the
> > padata enctype in the AS_REP with those it requested.
>
> What I did not spell out completely is that the KDC is setting the
> enctype in the padata PA-ETYPE-INFO2 to that of the client key which may
> not literally be what was in the AS_REQ.
Here is a proposed fix for the issue above:
Index: usr/src/cmd/krb5/krb5kdc/kdc_preauth.c
--- /ws/onnv-clone-aus/usr/src/cmd/krb5/krb5kdc/kdc_preauth.c Thu Dec 2 17:55:51 2004
+++ /export/willf/ws/sparc/6320871/usr/src/cmd/krb5/krb5kdc/kdc_preauth.c Mon Oct 3 13:17:30 2005
@@ -789,17 +789,17 @@
entry = malloc(2 * sizeof(krb5_etype_info_entry *));
if (entry == NULL) {
retval = ENOMEM;
goto cleanup;
}
entry[0] = NULL;
entry[1] = NULL;
retval = _make_etype_info_entry(context, request,
- client_key, client_key->key_data_type[0],
+ client_key, encrypting_key->enctype,
entry, 1);
if (retval)
goto cleanup;
retval = encode_krb5_etype_info2((const krb5_etype_info_entry **) entry,
&scratch);
if (retval)
goto cleanup;
I thought this fix would be appropriate as RFC4120 states:
If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
the AS-REP.
So using encrypting_key->enctype as the etype arg to
_make_etype_info_entry() seemed reasonable to me. Note that
encrypting_key->enctype is set in process_as_req() to the enctype in the
AS_REQ:
encrypting_key.enctype = useenctype;
--
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev
mailing list