Subject: RE: Do we have any consensus on the 8003 checksum--text follows this line--

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 6 Sep 2003 10:36:45 -0700

Jeffrey Hutzelman wrote:
>> > So, for the reply token I propose:
>> >
>> > {oid, tok id, AP-REP, extra-data, MIC({AP-REP, extra-data})}

>> Just encode this as { oid, tok id, XXX }
>> where XXX is a sequence of { type, length, value } tuples, with a
type 
>> reserved for the AP-REP, and another for the MIC (which must be
last).  
If 
>> other types are critical, then you probably should define an
IF-RELEVANT 
>> type, as we did with authorization data in kerberos-clarifications
(sec 
>> 5.2.6.1).

Would it be cleaner to insert an OPTIONAL "sequence of
sequence"-typed-hole at the end of EncAPRepPart of AP-REP?  I understand
Nicolas was trying to use only existing typed holes.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Saturday, September 06, 2003 9:59 AM
To: Nicolas Williams; Sam Hartman
Cc: [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum--text follows
this line--

On Friday, September 05, 2003 15:15:14 -0700 Nicolas Williams 
<[email-masked]> wrote:

> On Fri, Sep 05, 2003 at 04:46:02PM -0400, Sam Hartman wrote:
>>
>> It semes that we're fairly close to having rough wire encodings for
>> the AES GSSAPI mechanism.  One of the open issues still seems to be
>> how much effort we want to be to have a more correct usage of
Kerberos
>> messages and to avoid sticking GSSAPI options, extensions and
>> credentials in the checksum of an authenticator.
>>
>> How do we stand on this issue?
>
> I have no problem leaving the checksum data usage as it stands as
we've
> already broken that interface - I just wish it'd been used correctly
in
> the first place.
>
> As for the AP-REP token, we need a way to send stuff from the acceptor
> to the initiator for future GSS-API extensibility.  I am more than
happy
> to say: we'll cross that bridge when we get Kerberos extensions, but
Sam
> makes a good argument for crossing it now.
>
> So, for the reply token I propose:
>
> {oid, tok id, AP-REP, extra-data, MIC({AP-REP, extra-data})}

Just encode this as { oid, tok id, XXX }
where XXX is a sequence of { type, length, value } tuples, with a type 
reserved for the AP-REP, and another for the MIC (which must be last).
If 
other types are critical, then you probably should define an IF-RELEVANT

type, as we did with authorization data in kerberos-clarifications (sec 
5.2.6.1).