Subject: updated GSSAPI draft and summary of the off-list discussions

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 29 Aug 2003 16:46:17 -0700

The updated version for the GSSAPI draft is attached and here is a quick
summary of the major changes from -00:

1) pulled in context initiation tokens etc to make it standalone
2) added random-filler in Wrap tokens with confidentiality, to make the
header stay at the end of the decrypted data
3) changed to use the Flags field, instead of one-byte indicators

The summary of the extended hallway conversations among Sam, Nicolas,
Ken, JK, Paul, and me (this was initially compiled by Nicolas and I made
small modifications and updates):

1) There are constraints by existing SSPI applications (mostly written
for Kerberos) that supply either 3 buffers ("header", "data", and
"padding"), or two buffers ("header", "data"), thus it would cause
performance penalty if we want to keep the trailing checksum in the
on-the-wire format as specified in the simplified profiles. The solution
to this was Sam's rotation count proposal (RRC) - that is, rotate any
extra bytes that don't fit to the header buffer.  The alterative is to
shift the cipher text toward the header, which effectively defeats
in-place encryption.  

2) There was a significant discussion of AEAD encryption modes that
ended up with "too late for that" agreement.  The design of "mixed mode"
tokens was also discussed, but left for later (it would require updating
the GSS-API).

3) There was some discussion about adding support for future GSS-APIv3
negotiation to the context reply token, but we haven't really gone into
that.

4) After we settled the AEAD issue we discussed alignments between the
header and app data in the plaintext, as well as alignment requirements
of crypto HW scatter/gather interfaces.  The preference for nice
alignments led Nicolas to drop his suggestion of using
KRB-PRIV-X/KRB-SAFE-X as the basis of the wrap and MIC tokens.

5) The remaining issue is whether the wrap w/ confidentiality token
format should be 
(ignoring the RRC) 

header | encrypt(app data | header)

(as proposed by MS) or

header | encrypt(header | app data)

(as proposed by Nicolas).  

It was preferred to have the header at the end and also allow EC to be
used for data alignments.

Thanks. Larry

---

From: Luke Howard <[email-masked]>
Date: Sat, 30 Aug 2003 16:18:39 +1000

>3) changed to use the Flags field, instead of one-byte indicators

Should unknown flags be rejected or ignored? (I presume the former.)

>shift the cipher text toward the header, which effectively defeats

In the SSPI case, would the encrypted Wrap Token header also be
rotated?

-- Luke

P.S. I have updated our Heimdal implementation accordingly; should it
not be inthe next snapshot, contact me off-list and I'll send you a copy.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 30 Aug 2003 10:41:02 -0700

Luke Howard wrote:

>> Should unknown flags be rejected or ignored? 

>> (I presume the former.)

I would prefer that too.  

This change was made based on comments from the "design" team members;
we would love to hear more from the list. 

>> In the SSPI case, would the encrypted Wrap Token header also be

Yes, the encrypted Wrap Token header is rotated for existing SSPI
applications that do not supply the trailer buffer.  Please note that
the behavior depends on the applications.

Thx.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Luke Howard
Sent: Friday, August 29, 2003 11:19 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]; JK
Jaganathan; [email-masked]
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

-- Luke

P.S. I have updated our Heimdal implementation accordingly; should it
not be inthe next snapshot, contact me off-list and I'll send you a
copy.