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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 2 Sep 2003 22:46:29 -0700

Ken Raeburn wrote:

>> From the description of the authenticator "cksum" field:

>>      This field contains a checksum of the application data that
>>      accompanies the KRB_AP_REQ, computed using a key usage value of
10
>>      in normal application exchanges, or 6 when used in the TGS-REQ
PA-
>>      TGS-REQ AP-DATA field.

>> So, just send { AP_REQ, chan_bindings } and for the authenticator
>> checksum in AP_REQ, use the checksum of chan_bindings.

Is it possible to change the text above to fit with existing
implementations?

>> Not quite true -- throughout sections 8.3 and 8.4 you said "random
>> filler"; in this context, "random" doesn't mean "whatever you feel
>> like using", it implies the use of a random number source; whether a
>> weak PRNG would be acceptable or if a strong source is required might
>> be less clear.  That's why I explicitly used "unspecified".

I agree, how about this text:

  Filler is inserted between the plaintext-data and the "header", and
the    
  values and size of the filler octets are chosen by implementations 
  provided there is no crypto-system garbage added after the decryption.

>> I was thinking of messages much larger than 64K.  If you have a 300K
>> message, then under the current spec, you can move up to 64K from the
>> end to the beginning, but you can't move a small amount, say 256
>> bytes, from the beginning to the end.  (Like I said, I'm not sure if
>> we'd ever want to, just as I'm not sure we'd ever want to move more
>> than 32K from end to beginning.)

Do we have a reason to move the data from the head to the end? If you
are inclined, we can add a flag to reverse the rotation. 

I am somewhat concerned with encoding a signed number in the header. 

Sam/Nico, what do you think of supporting a signed rotation count?

>> Though you do bring up an interesting point.  If the message size is
>> 1K, can RRC be 2K, so that implementations may actually have to do
the
>> modular math?  Or should we require that RRC be smaller than the
>> message size (or 0 for an empty message)?

Modular math should be good enough.  Why would we forbid implementations
from, for example, right-rotating 16 bytes if the message size is 8
bytes?

>> It wasn't an implementation question.  Should we return
KEYTAB_NOMATCH
>> for anything keytab related, or should the messages instead be
>> oriented towards client credentials (usually credentials in a ccache,
>> maybe acquired via a long-term key stored in a keytab, whatever)
>> versus server credentials (stored in keytab, or ccache for
>> user-to-user, whatever)?  I think it should be the latter, and
>> mentions of keytabs and ccaches should not be in the generic error
>> messages, though perhaps an implementation may wish to use such
terms.

IMO, it is better if the messages are oriented towards credentials.  Can
you compile a complete/up-date list of minor codes (and their meanings)?
I am not totally up-to-date with respect to this aspect.

Thanks. 

Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2003 2:01 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

"Liqiang\(Larry\) Zhu" <[email-masked]> writes:
>>> Section 7.1: If we change anything in context initiation, we should
>>> try to move away from this bogus conjured-up "checksum as arbitrary
>>> octet string we can stuff data into" business.  In Clarifications
> (and
>>> probably RFC 1510, but I haven't double-checked), the checksum field
>>> of an authenticator is a checksum of associated application data,
and
>>> what RFC 1964 stuffs in there is no checksum.  (If we had AEAD, etc,
>>> etc.)
>
> It is a misnomer but otherwise benign. Is there another way to carry
the
> GSS checksum flags, the channeling binding information, and the
krb_cred
> message?

From the description of the authenticator "cksum" field:

      This field contains a checksum of the application data that
      accompanies the KRB_AP_REQ, computed using a key usage value of 10
      in normal application exchanges, or 6 when used in the TGS-REQ PA-
      TGS-REQ AP-DATA field.

So, just send { AP_REQ, chan_bindings } and for the authenticator
checksum in AP_REQ, use the checksum of chan_bindings.

>>> I'm not sure that including EC in the checksummed data for
>>> Wrap-without-confidentiality gains us much either. 
>
> EC is used as an attempt to separate plaintext data from checksum.
> Since the EC filed does not need to be protected, to avoid
"chicken-egg"
> dilemma, we can fill EC with zeroes when we calculate the checksum.

That would work, yes.

> Having the header at the end has the added benefit of preventing
> "message extension" attacks (that is an attacker can add additional
data
> to the end of a message without recalculating the checksum for the
> existing message), which is not applicable to HMAC checksums in
> simplified profiles.

Under what circumstances can these message extension attacks be
performed?  Should we be worried about any of our existing
cryptosystems being unsuitable for general use?

> Should we add the restriction to make checksum have fixed sizes? What
> does the variable-size checksum buy us? In general, I would also
prefer
> to remove non-essential generality, which generally means simplicity.

What's essential and what's not?  Until the RC4 implementation came
along, I probably wouldn't have bothered with non-block-cipher
support.  I don't want to constrain things too much through
short-sightedness.  But at the same time, too many options do require
that the application protocol be able to handle them.

I'm not convinced these extra constraints are all needed.  Seems like
a lot of hoops to jump through to avoid incorporating an 8-byte (or
one-block) length field at the front of the application data.

> It was suggested to allow EC for alignments.  There is indeed
ambiguity
> on how the filler bytes are chosen, and we did not give any guidelines
> how to choose the filler bytes:

Not quite true -- throughout sections 8.3 and 8.4 you said "random
filler"; in this context, "random" doesn't mean "whatever you feel
like using", it implies the use of a random number source; whether a
weak PRNG would be acceptable or if a strong source is required might
be less clear.  That's why I explicitly used "unspecified".

> Also do we really want to say "padding" here?

I think "filler" is better, "padding" could be ambiguous, describing
the filler inserted by the mechanism and the trailing junk added by
the cryptosystem.

>>> Section 8.5: So, RRC is treated as an unsigned value?  The rotation
>>> can't go the other way?  (No, I don't have a good example at the
>>> moment why you might want to do it that way.)  I don't remember if
we
>>> decided anything in our off-list discussions.
>
> We need to handle messages less than 64k, the "net" RRC should be
> interpreted as "RRC mod m", where m is the size of the encrypted data.
> That is, for example, if the encrypted data size is 8, if you want to
> right rotate -3 bytes, you can just right rotate 5 bytes. So it is
> effective signed.
>
> I think most people would have the impression that a reminder is
always
> non-negative and that is ok here.

I was thinking of messages much larger than 64K.  If you have a 300K
message, then under the current spec, you can move up to 64K from the
end to the beginning, but you can't move a small amount, say 256
bytes, from the beginning to the end.  (Like I said, I'm not sure if
we'd ever want to, just as I'm not sure we'd ever want to move more
than 32K from end to beginning.)

Though you do bring up an interesting point.  If the message size is
1K, can RRC be 2K, so that implementations may actually have to do the
modular math?  Or should we require that RRC be smaller than the
message size (or 0 for an empty message)?

>>> Can an implementation acting as initiator use a keytab for storing
> the
>>> client's long-term key?  If so, do you return KEYTAB_NOMATCH if the
>>> client principal name doesn't match anything in the keytab?
>
> MS does not return minor codes, can you double check to verify this?

It wasn't an implementation question.  Should we return KEYTAB_NOMATCH
for anything keytab related, or should the messages instead be
oriented towards client credentials (usually credentials in a ccache,
maybe acquired via a long-term key stored in a keytab, whatever)
versus server credentials (stored in keytab, or ccache for
user-to-user, whatever)?  I think it should be the latter, and
mentions of keytabs and ccaches should not be in the generic error
messages, though perhaps an implementation may wish to use such terms.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 03 Sep 2003 17:56:20 -0400

> Is it possible to change the text above to fit with existing

I'd recommend using a new context establishment token id, so this
would be in the description of the new token.  Compatibility with
existing implementations would indicate that the old (01 00) context
establishment token should be used (without any extensions) when it's
not known that the updated mechanism is supported.

>   provided there is no crypto-system garbage added after the decryption.

"Provided" implies a constraint; something like "such that" is more
indicative of a purpose as well.  The constraint concerning decryption
trailing bytes applies to the choice of the filler size, but *not* to
the choice of values (if any).

Also, I'm not crazy about the word "garbage" in this context.

> are inclined, we can add a flag to reverse the rotation. 

Why a flag instead of a signed number?  Sign extension isn't that big
a deal.  But no, I don't have a contrived case ready at the moment.
I'm not planning on doing any rotation stuff in our implementation
anyways.

> from, for example, right-rotating 16 bytes if the message size is 8

Because it requires that every receiver do the modular math, with no
possible benefit that I can see.  If I send a 16-byte message and a
rotation count of 19745 bytes, what can you *possibly* do with it
besides a modulus operation?

BTW, it occurred to me later, with the copy of the header always
included, a plaintext size of 0 shouldn't possible, so my suggested
constraint would simply be that RRC should always be less than the
message size.

> I am not totally up-to-date with respect to this aspect.

I'll take a look.  I'm not either.

Ken