Subject: GSSAPI/AES draft

From: "JK Jaganathan" <[email-masked]>
Date: Sun, 17 Aug 2003 11:39:16 -0700

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: Nicolas Williams <[email-masked]>
Date: Mon, 18 Aug 2003 08:47:27 -0700

One thing I note is that this draft does NOT require recalling kcrypto
to add AEAD modes.  I would appreciate a clarification as to whether you
still think that kcrypto needs recalling.  As far as I can tell, neither
Sam, nor Ken (and certainly not I) support recalling kcrypto if there's
any way to get a Kerberos V GSS-API that is generic to kcrypto enctypes
without recalling kcrypto - something your draft seems to aim for and
achieve.

I am still mystified as to why we need the sequence number in the clear
in the wrap token.  In private we've discussed stream cipher based
enctypes where one wishes to chain cipher state across tokens, but as
we've seen (in the private thread) such a construction does not fit
within the GSS-API, and there may well be cheap alternatives to solving
the problem of re-initializing stream cipher state [w/ derive keys] for
every encryption anyways.

Now, I do not oppose having the sequence number in the clear in
confidentiality-protected wrap tokens, but if doing so may lead to
enctype designs that violate the GSS-API then we have a problem.

I think proponents of stream cipher based enctypes need to go study the
possibility of defining key derivation in terms of "cipher state
derivation" or something like it, to avoid both, the cost of setting up
the key state for each encryption and breaking the GSS-API.  Or perhaps
they need to study stream ciphers with inexpensive key derivation and
key setup.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Aug 2003 22:15:01 +0200 (MET DST)

> enctype designs that violate the GSS-API then we have a problem.

Just some extra info on message sequence numbers in GSS-API:

Although the GSS-API spec seems to offer out-of-order processing
of protected messages, this normally doesn't work, and "portable"
applications or Kerberos-gssapi-based applications shouldn't try
to do this.

The primary problem is which error codes are appropriate for
the various situations and how to "recover" after processing an
unsequenced message.  My GSSTEST program has an error testing mode
that also simulates a reordered message stream -- and it shows
for MIT Kerberos that it doesn't recover by itself.

The reason may be an inappropriate API definition -- this is
the single case where Microsoft's SSPI spec is slighlty more adequate,
because there the application may provide app-level sequence numbers with
message un/protection calls.

The only gssapi mechanisms that can handle unsequenced messages
are probably those that do *NOT* support sequence and replay protection
on protected messages.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 14:22:04 -0700

> applications or Kerberos-gssapi-based applications shouldn't try

Implementation bugs aside I see nothing wrong with the GSS-API spec wrt
out-of-sequence detection except that it would be nice if sequence
numbers [normalized to zero-start] were exposed.

The spec is quite clear that the oos/replay error codes are
supplementary to GSS_S_COMPLETE and that oos/replay detection errors can
only be returned when the token could be verified/unwrapped successfully
otherwise.

> are probably those that do *NOT* support sequence and replay protection

Certainly NOT true.  The Kerberos mechanism easily handles contexts with
and without either replay or out-of-sequence detection.

ONC RPC w/ RPCSEC_GSS is an example of a GSS-API application that does
its own sequence and which never requests oos/replay detection from the
GSS-API and which works just fine with the rfc1964 Kerberos V GSS-API
mechanism.

Cheers,

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Aug 2003 00:17:10 +0200 (MET DST)

> only be returned when the token could be verified/unwrapped successfully

They are clear only because I requested them to be clarified this
way very late in the GSS-API v2 standardization.  Very few applications
will probably conform to this, i.e. I don't expect MIT Kerberos to
do the pairing of Sequencing-related errors with GSS_S_FAILURE although
the spec recommends this and MIT Kerberos makes these error fatal.

> and without either replay or out-of-sequence detection.

Sorry, but that is true.

If you request replay protection on a security context established
with MIT Kerberos, you get enforced sequencing, and out-of-order
processing of messages is then impossible.

> GSS-API and which works just fine with the rfc1964 Kerberos V GSS-API

In case that Kerberos offers security contexts without sequencing
and without replay protection this might be possible -- and is almost
what I claimed.  I have never tried doing that.  I hope that
RPCSEC_GSS documents this special usage properly.

Does it also work with existing Kerberi that use RC4 encryption?

For their NTLM SSPI-mechanism Microsoft made two stupid mistakes
which cause severe usability problems: (1) they use a single continuous
keystream for all messages so that processing out of order
is impossible and (2) they use the same keystream for both
directions making the security context synchronous half-duplex...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Aug 2003 16:37:53 -0700

> way very late in the GSS-API v2 standardization.  Very few applications

Thank you.

> the spec recommends this and MIT Kerberos makes these error fatal.

We define those errors as follows (from the C headers):

#define GSS_S_DUPLICATE_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
#define GSS_S_OLD_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
#define GSS_S_UNSEQ_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
#define GSS_S_GAP_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 4))

and those are returned by gss_verify_mic()/gss_unwrap().

Note that there's no reference to GSS_S_FAILURE.

> processing of messages is then impossible.

I misunderstood what you meant by "unsequenced."  Yes, it's possible
that MIT's and/or Sun's implementations have problems with oos, but
those would not be the result of a bad spec (either rfc2743, rfc2744 or
rfc1964).

> RPCSEC_GSS documents this special usage properly.

It certainly does.  See RFC2203.

Some applications do use replay detection just fine too (e.g., FTP).

Are there any applications that actually use oos?

> Does it also work with existing Kerberi that use RC4 encryption?

Good question.

> directions making the security context synchronous half-duplex...

That's not my reading of draft-brezak-win2k-krb-rc4-hmac-04.txt.

In any case, the GSS-API does not support what you say MS did.  The
problem is that key setup can be expensive for some stream ciphers, thus
encouraging one to minimize key setups; one solution might be to define
a cheap, but secure, cipher state derivation function (as opposed to key
derivation function) so that key setup can be done once and cipher state
cna be derived at low cost for each encryption operation).

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Aug 2003 09:34:34 -0400

In general, this draft looks good.  I wouldn't object if the working
group decided to take this draft as the basis for our GSSAPI
direction.

I consider the following issues to be minor, but since I noticed them
I thought I would bring them up.

I'm not convinced the current draft handles block cipher alignment in
the general case, but I believe I have personal mail discussing that
issue.

There is inconsistent text on backwards compatibility.  Section 3
seems to assert a requirement that the new token formats not be used
with older algorithms.  Section 7 seems to allow it but discourages
it.

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.

Do we want to make this draft stand on its own and define context
establishment tokens, or do we want it to simply be an adjunct to RFC
1964?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 08:39:51 -0700

> the general case, but I believe I have personal mail discussing that

I think it does as an option, but implies that implementors that want to
have nice cipher block alignments will have to have kcrypto cipher block
sizes be visible to the mech.  I think this is acceptable even though
kcrypto does not expose cipher block sizes.

(If kcrypto is recalled, let's make cipher block sizes visible.)

> Kerberos need not implement the old token formats.  I would also be OK
> with consistently forbidding use of new tokens with old algorithms.

Agreed.  The text could read:

   These token formats MUST be used with all "newer" enctypes
   [clarifications] and MAY be used with "older" enctypes, provided that
   the initiator and acceptor know, from the context establishment, that
   they can both process these new token formats.

   "Newer" enctypes are those which have been specified along with or
   since the new Kerberos cryptosystem specification [kcrypto]
   [clarifications].

> establishment tokens, or do we want it to simply be an adjunct to RFC

I would like to see additional text describing how the AP-REQ checksum
data can be extended.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 12:37:03 -0500

> I would like to see additional text describing how the AP-REQ checksum

We've discussed before possible GSS-API v3 features and how some such
features may have to be negotiated at the mech layer.  (One such feature
was context re-keying.)

Unfortunately, there is no AP-REP equivalent of the checksum field in
the AP-REQ authenticator.

Should the mech specifically have support for adding negotiation of such
features later?  Or should we rely on Kerberos extensions to add a typed
hole to the AP-REP?

One WG member has opined, privately, that we should not wait for
extensions.  I could go either way.

And note that we cannot yet define the contents of an acceptor-side
equivalent of the AP-REQ checksum 0x8003 data.

If we choose to add support for feature negotiation now we'll have to
change the response context token to include not only an AP-REP but also
the feature negotiation data (initially null) and a MIC binding the two
(or should the feature negotiation data should be confidentiality
protected?).

Opinions?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 11:28:55 -0700

> the general case, but I believe I have personal mail discussing that

My interpretation is that the cipher block sizes, or rather, scatter/
gather crypto interface alignment requirements/preferences (where there
are any) would be internally visible to mech implementations of
GSS_Get_MIC() and GSS_Wrap() that use such interfaces.

Implementations of GSS_Verify_MIC() and GSS_Unwrap() would not be
affected, of course, except in so far as they should ignore the EC pad
bytes.

But I'm starting to think that the header shouldn't float on the end of
the app data, but that the app data should float on the end of the
header.  That's so that the EC field can be integrity verified before
running into the EC padding octets.

I.e., section 6.2, second paragraph, second sentence should say

{"header" | encrypt("header" | [EC padding] | plaintext-data)}

rather than

{"header" | encrypt(plaintext-data | "header")}.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 19 Aug 2003 16:36:23 -0400

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