Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Aug 2003 04:24:20 -0700

Ken Raeburn wrote:

>> Section 6.3: Do we need a 16-bit rotate count?  I would think a
signed 8->> bit value would be enough.  Again, not a huge deal in terms
of token >> >> space savings, but if an implementation (like MIT's)
wants to feed an >> >>"un-rotated" buffer to its decrypt routine, it's
got to have the space >>free to reverse that rotation; the easiest way
is with an extra buffer >>with a size indicated by the rotate count.  If
we get checksums or other >>trailing data larger than 127 bytes any time
soon, I'm going to be >>concerned.  (And further off in the future,
you're going to have SSPI >>updated so the trailing buffer is always
there, right?)

How about changing text to say something like "RRC <= 4096 MUST be
supported"? I suspect 512 bit checksum would come sooner than we would
expect. 4096 would definitely give us enough migration time.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, August 19, 2003 1:36 PM
To: [email-masked]
Subject: Re: GSSAPI/AES draft

This draft looks good, I think we're going in the right direction now.

Some comments, from my first reading:

I think the plaintext length should be included in the Wrap token, not
the size of the padding.  (Details sent privately in response to some
other email.  Short version: I can envision some odd but compliant
Kerberos cryptosystems where the padding size could be dependent on
the data stream contents, so encoding the size of the padding into the
data stream would be an iterative process, possibly without a stable
solution.)  The length should probably be 8 bytes.

The length is needed even if confidentiality is not provided.  There
is no requirement in the checksum profile that the output be of fixed
length, so you need some way to separate them.

Section 6.3: You don't explain why the RRC is needed for in-place
encryption.  It's only needed if you combine that with the
no-token-trailer requirement.

Section 6: You list things that SSPI "allows", and also refer to
"requirements".  If certain requirements on the mechanism come from a
desire to let SSPI continue to do certain things that improve
performance, spell it out that way.

I think I'd like to see the SSPI requirements listed explicitly in a
separate section, which should probably have "(Informative)" in its
title since it's part of the justification, not part of the
specification.  The in-place encryption in properly aligned buffers I
grant would be a general performance improvement in implementations
that take advantage of it, but the lack of the trailing buffer I see
mostly as just an SSPI constraint.  (Yes, fewer buffers means easier
manipulation, but I don't think it's that big a deal.)  SSPI should
have an entry in the References section.

Speaking of aligned buffers... is nothing going to be done in that
department?

Section 6.2: When you describe "encrypt()", how about explicitly
mentioning the inclusion of integrity protection, to make it clear?

Section 6.6: The Wrap token diagram doesn't adequately describe the
case of no integrity protection.

Section 6.6: It's nit-picking, but... I'd use "2" for the one-byte
"range", and "16..last" or "16..N" or something for the "rest of the
token" part.

Sections 6.1, 6.5: The Direction and Seal fields effectively only need
one bit each.  Probably not a big deal, since we could only squeeze
out one byte from the Wrap token at the moment anyways.

Section 6.3: Do we need a 16-bit rotate count?  I would think a signed
8-bit value would be enough.  Again, not a huge deal in terms of token
space savings, but if an implementation (like MIT's) wants to feed an
"un-rotated" buffer to its decrypt routine, it's got to have the space
free to reverse that rotation; the easiest way is with an extra buffer
with a size indicated by the rotate count.  If we get checksums or
other trailing data larger than 127 bytes any time soon, I'm going to
be concerned.  (And further off in the future, you're going to have
SSPI updated so the trailing buffer is always there, right?)

Section 7, last sentence: All enctypes are described by crypto
profiles.  Refer to specific stuff in [KRBCLAR].

Section 3, next to last paragraph: Make more specific references to
[KRBCLAR].

Section 5: I think the Wrap tokens without confidentiality should use
the -SIGN key usage values -- i.e., one value for encryption, a
different value for checksums, in each direction.

Section 8, last paragraph: Hash function size is not a concern for
this document.  If there's a problem with SHA-1 for AES, it should be
in the Security Considerations for the AES draft, not here.  I think
this paragraph can just go away.

Sections 6.2, 3: Since AES is only mentioned in 6.2 (except for the
reference in section 8 which I said should go away), you can drop the
mention in section 3, and say "aes128-cts-hmac-sha1-96 or
aes256-cts-hmac-sha1-96 [AES-KRB5]" in section 6.2.  Start that
paragraph with "for example", because it is an example, not an
explicit specification for how one special cryptosystem should be
handled.  All of the information in that paragraph should be easily
derived from AES-KRB5 and the rest of 6.2.

Section 10: References are supposed to be in two sections, "Normative
References" and "Informative References".

Section 6.6: I don't know what you're using for formatting the draft,
but see if you can get it to keep the token format layout tables
entirely contained on one page instead of straddling page boundaries.

General: It would probably also look a little better if there were
always a blank line before the footer.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 21 Aug 2003 15:09:48 -0400

> expect. 4096 would definitely give us enough migration time.

Yes, but that's still only 64 bytes.  (RRC does count bytes, right?)
Do you expect a 1024-bit checksum to come along become the SSPI
trailing buffer problem is dealt with?

And why talk about certain ranges that MUST be supported?  Do you
expect different implementations to impose different limits on RRC, so
that they might not interoperate?  I think the full expressable range
of values should be supported.

If you think more than 8 bits are needed, then how about making it 10
or 12 bits, and stealing an upper bit for the direction flag?

Ken

---

From: Luke Howard <[email-masked]>
Date: Wed, 27 Aug 2003 12:45:01 +1000

FYI the latest Heimdal snapshot includes a preliminary implementation
of draft-ietf-krb-wg-gssapi-cfx-00.txt:

ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-20030827.tar.gz

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 Aug 2003 21:21:13 -0700

> ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/heimdal-20030827.tar.gz

Please note:

 - draft-ietf-krb-wg-gssapi-cfx-00.txt has not been submitted to the
   IETF, just to this WG

 - expect the draft that will be submitted to the IETF will be somewhat
   different from -00, incompatibly so

Cheers,

Nico
--