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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 5 Sep 2003 17:08:32 -0700

Nicolas Williams wrote:
>> {oid, tok id, AP-REP, extra-data, MIC({AP-REP, extra-data})}

How does the receiver separate the MIC from extra-data?

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Friday, September 05, 2003 3:15 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum--text follows
this line--

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})}

A length of extra data, and maybe a length of the AP-REP will have to
be included.  The extra data could initially be empty, or it could start
out containing only an integer field for a status code (so we can have
errors unrelated to accepting the AP-REQ communicated to the client
securely).  Additions to the extra data should be CRITICAL (the acceptor
should not include any additions unless the initiator indicated support
for them and initiators should consider any unknown additions to be
an error.  Finally, the extra data should probably be like a typed hole.

As for the AP-REQ token, we can leave the original gss flags, channel
binding and KRB-CRED text in place, while also adding some text about
any additions past the deleg option being NON-CRITICAL (i.e., the
acceptor is to ignore any such additions if it does not recognize them).

This way we can define extensions for the gss data when we get to need
them.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 17:09:43 -0700

> How does the receiver separate the MIC from extra-data?

The the paragraph of that post that starts with "A length of extra
data..." (i.e., the length of the extra data would have to go in the
clear and be included in the MIC.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 17:12:28 -0700

> The the paragraph of that post that starts with "A length of extra

That should be "See the paragraph ..."