Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 17 Aug 2003 14:46:39 -0700

Some additional notes for this draft might help:

1) new TOK_IDs, this enables us to remove algorithm indicators, this can
reduce overhead especially for small messages.
2) "floating trailer", aka the RRC field (right rotation count), this
allows for in-place encryption.
3) the trailing header in the encrypted data, that is the
encrypt(plaintext-data | "header") in the draft, this allows for
"scatter-gather" without incurring performance penalty related to data
alignment requirements by underlying crypto systems.
4) the inclusion of 64 bit sequence number and directional keys (plus
another directional indicator): this has been discussed on list. Thanks
to Ken.
5) EC field in the token header, aka the "extra count" field, this
allows us to avoid un-necessary overhead, for encryption types such as
AES, encoding an 8 byte length for the plaintext data in the Wrap token.

6) the support of the Kerberos crypto framework with full generality,
this is a big plus.

This draft has taken significant input during the off-list discussions
after we sent it our earlier version of this draft to seek for comments.
The acknowledgement section listed contributions by Nicolas Williams,
Sam Hartman, and Ken Raeburn.

JK and I will be more than happy to take comments and questions.

Thanks. Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of JK
Jaganathan
Sent: Sunday, August 17, 2003 11:39 AM
To: [email-masked]
Cc: JK Jaganathan
Subject: GSSAPI/AES draft

Here is the draft that folks at Microsoft have been working on with
considerable input from Ken, Nico, and Sam. The draft had been in limbo
for sometime ever since I sent Ken a primitive version several months
ago. 

The current draft is much more mature and we even have a partial
prototype based on an earlier version. It also addresses our concerns
with respect to compatibility with SSPI based applications. 

Larry and I felt it was appropriate that we share it with the WG at this
point as it is significantly different from Ken's draft.

---

From: "JK Jaganathan" <[email-masked]>
Date: Wed, 20 Aug 2003 21:43:53 -0700

Piggybacking on the extensions negotiation mechanism certainly seems
like
a possible alternative and saying "a sender SHOULD NOT use the new
tokens
 with old enctypes _unless_ it has prior knowledge of its peer's 
ability to handle the new tokens" does leave enough room to consider
other
 options . I will change the text to reflect this.  

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Wednesday, August 20, 2003 9:24 PM
> To: JK Jaganathan
> Cc: Sam Hartman; [email-masked]
> Subject: Re: GSSAPI/AES draft
> 
> On Wed, Aug 20, 2003 at 09:12:03PM -0700, JK Jaganathan wrote:
> > > From: Sam Hartman [mailto:[email-masked]]
> > > Sent: Wednesday, August 20, 2003 6:35 AM
> > > 
> > > I think I prefer the approach in section 7.  i would 
> recommend that 
> > > we require implementations support the new token formats even for 
> > > old algorithms, so that for example a pure extensions 
> implementation 
> > > of Kerberos need not implement the old token formats.  I 
> would also 
> > > be OK with consistently forbidding use of new tokens with old 
> > > algorithms.
> > 
> > I think we should forbid the generation of the new token format for 
> > older algorithms (being conservative in what we send) and recommend 
> > that implementations be able to accept the newer tokens 
> even when the 
> > key type specifies an older algorithm(being liberal in 
> accepting). If 
> > we start sending newer tokens for older algorithms the interop 
> > problems with the older versions just blow my mind.
> 
> Once we have Kerberos extensions off the drawing board it 
> makes sense to always use the new token formats between peers 
> that both support extended Kerberos.  That was Sam's point.
> 
> To specify this now all we have to do is say that "a sender 
> SHOULD NOT use the new tokens with old enctypes _unless_ it 
> has prior knowledge of its peer's ability to handle the new 
> tokens" - with extensions both peers would know that they 
> both support the new tokens if the they know that they both 
> support Kerberos extensions, which, in turn, they'll know 
> from the AP exchange in the context tokens.
> 
> > Accepting the newer token formats for the older algorithms 
> doesn't buy 
> > us much(assuming everyone implements this correctly) but 
> does give us 
> > some flexbility in the future - so it is not strictly 
> required and I 
> > am ok with cutting it. If we pass the buck to the 
> implementation and 
> > say 'use the newer format if you can determine that both sides can 
> > understand it' it will never really work across different 
> > implementations as each might use its own mechanism.
> 
> It will work with Kerberos extensions.
> 
> > If we really want to do away with the older token formats 
> then I think 
> > we should just define new enc types(for use with the newer 
> tokens) for 
> > the older algorithms.
> 
> This would just another way to negotiate support for the new 
> token formats, but we already know that we'll be negotiating 
> support for Kerberos extensions anyways, so we will have an 
> appropriate method of mech version negotiation.
> 
> (The Kerberos extensions negotiation will happen in the KDC exchanges.
>  If a client uses extended KDC exchanges and the target 
> principal  supports extended Kerberos then the KDC will 
> return an extended ticket,  which will inform the client that 
> the target principal support extended  Kebreros [and the new 
> GSS mechanism].)
> 
> Nico
> -- 
> 
>

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Aug 2003 03:12:36 -0700

Ken Raeburn wrote:
>> 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.

Indeed. This can be done in conjunction with changes suggested by
Nicolas for floating the header to the front of the data.

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

If we can assume the checksum size is no more than 64k, we can reuse the
EC field to encode the checksum size. Should we try to minimize the
overhead here, especially for small messages? Fortunately the name "EC"
is generic enough that it is suitable for this too.

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

This should be clarified.

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

Reference for SSPI should be added. Nicolas, you were mentioning
scatter-gather interfaces, do you have some references we can cite too
(in addition to that it is implemented in SSPI).  Another point is that
should we limit the reference of in-place encryption (and
scatter/gather) to SSPI only?

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

Can you elaborate?

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

This sounds good. 

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

We will try to reword this to make it clearer.

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

This is where I would disagree. What I see is that you can do it either
way, in the rc4_hmac_draft the usage value used by Wrap tokens does not
depend on whether confidentiality is provided for by the wrap tokens.
Unless you have a strong reason doing it otherwise, we would leave it
this way.

The rest of comments that are not explicitly mentioned above will be
automatically incorporated into the updated version.

We will send out the updated version once we can settle down on the
encoding of the plaintext data length, which seems to be the only major
outstanding issue now.

We will also add some initial text for considerations of the checksum
type 0x8003, as suggested by Nicolas. This can open up more discussions.

Thanks. Larry

-----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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Aug 2003 19:50:25 -0700

Ken Raeburn wrote:
>> Yes, but that's still only 64 bytes.  (RRC does count bytes, right?)

Ah, you are right here.

>> Do you expect a 1024-bit checksum to come along become the SSPI
>> trailing buffer problem is dealt with?

What I can see is that the checksum size can go up easily. Say you want
to have 512-bit keys (I do not see that as outlandish), you might have
your eyes at 1024-bit checksums as well.

>> 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?

I am not yet convinced that the 16 bit rotation count can be an issue (I
think it might be avoided if you do not copy the cipher text data).
Although keeping numbers small is in general a good idea, I do not see a
huge difference between 4k and 64k.  I like it this way because it is
symmetric to the size of the EC field, both should be on the "order" of
the cipher block size.

We will send an updated version either end of this week or earlier next
week. 

If you see it still as an issue in the updated draft, please get back to
this thread again.  

Thanks, Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Thursday, August 21, 2003 12:10 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: GSSAPI/AES draft

"Liqiang\(Larry\) Zhu" <[email-masked]> writes:

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

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: Sat, 23 Aug 2003 15:21:46 +1000

You define:

KG-USAGE-ACCEPTOR-SIGN	22
KG-USAGE-ACCEPTOR-SEAL	23
KG-USAGE-INITIATOR-SIGN	24
KG-USAGE-INITIATOR-SEAL	25

For existing implementations that have KG-USAGE-SEAL as 22 and 
KG-USAGE-SIGN as 23, would it make sense to invert these:

KG-USAGE-ACCEPTOR-SEAL	22
KG-USAGE-ACCEPTOR-SIGN	23
KG-USAGE-INITIATOR-SEAL	24
KG-USAGE-INITIATOR-SIGN	25

-- Luke