[1909] in Kerberos-V5-bugs
Re: Krb5 beta5 defect report
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri May 3 17:56:16 1996
Date: Fri, 3 May 1996 17:55:57 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Sean Mullan <mullan_s@apollo.hp.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Sean Mullan
<mullan_s@apollo.hp.com>,
krb5-bugs@MIT.EDU, champine@apollo.hp.com, bcn@isi.edu
In-Reply-To: Sean Mullan's message of Fri, 03 May 1996 15:51:47 -0400,
<199605031951.AA130653109@relay.hp.com>
Date: Fri, 03 May 1996 15:51:47 -0400
From: Sean Mullan <mullan_s@apollo.hp.com>
However, I think this particular problem also exists in pre-beta 6.
(I'm not sure if you are implying that this defect is fixed by the
new preauth handling but from a cursory look at the sources, I still
think it is a problem, but I could be wrong).
Yes, I've dealt with this problem already in pre-beta 6. What happens
is that get_in_tkt() will request a ticket with no preauthentication.
If preauth is required, the KDC returns KDC_ERR_PREAUTH_REQUIRED and the
e-data field in the error table contains a sequence of PA-DATA ASN.1
structures. (This is currently specified by RFC-1510.)
In this sequence, one of the PA-DATA structures will have padata-type[1]
set to the pseudo preauth type KRB5_PADATA_ETYPE_INFO. The
padata-value[2] of this structure will then contain the ASN.1 encoded
octet string for an ETYPE-INFO structure, which is defined as follows:
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype[0] INTEGER,
salt[1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
KRB5_PDATA_ETYPE_INFO is a new preauth type, that will be documented in
RFC-1510bis. Unfortunately, we had to introduce a new preauth type,
since otherwise there was no place to put this extra data. But this
will be documented in the next version of the Kerberos V5 specification.
I thought long and hard before implementing this code in our pre-Beta 6
development sources, and I believe it is the cleanest way to provide the
functionality which is so critically necessary to support multiple
encryption systems as well as multiple salt types using
preauthentication. I suggest that if you try to solve this problem in
the your HP/DCE sources, you adopt this solution so that we can be
interoperable.
- Ted
