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

From: [email-masked] (Sam Hartman)
Date: Fri, 5 Sep 2003 16:46:02 -0400 (EDT)

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?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 15:15:14 -0700

> 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: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 06 Sep 2003 12:58:57 -0400

> {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).

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 6 Sep 2003 13:57:46 -0700

> type, as we did with authorization data in kerberos-clarifications (sec 

Sure, we know how to design this sort of thing (and note that this being
a context token use of ASN.1 would be fine, as nice alignments and
performance aren't very relevant in this context).  I'd like to get
consensus that this is the way to go.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 7 Sep 2003 00:39:25 -0700

> consensus that this is the way to go.

Ok, now that I'm thinking about the structure details; one possible
design would be:

{ oid, tok_id, DER encoding of REP-TOKEN }

where REP-TOKEN is:

   -- [explicit tagging environment]
   REP-TOKEN ::= CHOICE {
      krb-error [0] KRB-ERROR,
      rep-token [1] SEQUENCE {
         body      [0] REP-TOKEN-BODY,
         mic       [1] OCTET STRING OPTIONAL -- a MIC of the body
      }
   }

   REP-TOKEN-BODY ::= SEQUENCE {
      ap-rep     [0] AP-REP,
      status     [1] UInt32, -- major status
      gss-flags  [2] GSS-FLAGS, -- a bit string, like gss flags in init token
      options    [3] SEQUENCE OF SEQUENCE {
         option-type  [0] Int32,       -- mech option type
	 option-data  [1] OCTET STRING -- mech option
      }
   }

   -- UInt32 and Int32 are as in clarifications
   -- GSS-FLAGS is a BIT STRING with named bits
   -- ...

[The MICed data would include the AP-REP in spite of the fact that
 technically the MIC would be bound to the context anyways - this is
 because it would be easier to verify the connection if the AP-REP is
 included in the MICed data than if it isn't (if it isn't then the
 sequence number has to be verified, which breaks the GSS sequence
 number abstraction and so would complicate the implementation).]

The init token would have the same options typed hole added to the end
of checksum 0x8003 data.

This could be useful even today.  For example, consider negotiation of
confidetiality ptoection: Sun used to ship a crippled version of the
rfc1964 mech that didn't support conf_flag for export purposes and a
domestic version that did - currently a non-crippled initiator asking
for confidentialilty protection from a crippled acceptor can only get a
KRB-ERROR reply, as opposed to an AP-REP and an integrity protected
indication that the server does not support confidentiality.

Cheers,

Nico
--