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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 2 Sep 2003 23:05:35 -0700

Nicolas Williams wrote:

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

>> IIRC, from the off-list discussion, MS will fix the SSPI to make
usage
>> of the RRC go away, so even though the RRC field is too small to
support
>> use of the current SSPI with general kcrypto enctypes, it's just fine
>> for now.

That is right: the "4-buffer" application model is more flexible for
future extensions.

Larry

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

On Tue, Sep 02, 2003 at 05:01:15PM -0400, Ken Raeburn wrote:
> So, just send { AP_REQ, chan_bindings } and for the authenticator
> checksum in AP_REQ, use the checksum of chan_bindings.

Quite reasonable.  And not just the channel bindings either, but the
GSS flags, the optional KRB-CRED, and any extensions.

The reply token format could be {AP-REQ, GSS_Wrap(gss reply data)} where
<gss reply data> would be empty for GSS-APIv2 uses but possibly
non-empty for future v3 uses.

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

Are you referring only to Larry's proposed constraint that checksums be
fixed-sized?  Or are you referring to the other constraints we've
already agreed on?

If the latter, I suppose it would be useful to have some information
about the length distribution of wrapped data in real-life uses of the
GSS-API.  NFSv2/3/4, FTP and DCE RPC are some commonly used protocols
where performance matters and which use or can use the GSS-API.

[...]
> 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.)

IIRC, from the off-list discussion, MS will fix the SSPI to make usage
of the RRC go away, so even though the RRC field is too small to support
use of the current SSPI with general kcrypto enctypes, it's just fine
for now.

Cheers,

Nico
--

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Sep 2003 02:04:22 -0700

Ken Raeburn wrote:

>> Well, in general, most of them aren't needed, but we have agreed on
>> some for purposes of optimization and SSPI compatibility, haven't we?
:-)
>> But now, I think we're adding more, and I don't think we discussed
>> them.  And we haven't said, "oh, whatever, go ahead and add whatever
>> constraints you want".  So, new constraint, more discussion.

There were not a lot of discussions about the checksum before and
perhaps we should have some.

I am not pushing for adding new constraints for the checksum, but if we
find a good reason to have some, we should look into it.  I believe Luke
and I might just find one of such reasons.  Let's bring back to the list
once we get more details.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, September 02, 2003 6:36 PM
To: [email-masked]
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

> GSS flags, the optional KRB-CRED, and any extensions.

Um, yeah.  The whole thing.  Actually, the channel bindings are known
to both sides, just the MD5 hash is used, so the hash would presumably
be used again in this case.  (Yet another plug for AEAD.)

> non-empty for future v3 uses.

The reply token should be using AP-REP, shouldn't it?  There's no
place there for an additional checksum.  So we'd need a checksum for
the reply data.

> fixed-sized?  Or are you referring to the other constraints we've

Well, in general, most of them aren't needed, but we have agreed on
some for purposes of optimization and SSPI compatibility, haven't we?
:-)
But now, I think we're adding more, and I don't think we discussed
them.  And we haven't said, "oh, whatever, go ahead and add whatever
constraints you want".  So, new constraint, more discussion.

> where performance matters and which use or can use the GSS-API.

That would be useful anyways.  In fact, I was going to send a note to
krbdev on a related matter, key scenarios for measuring the MIT
implementation performance.

support
> use of the current SSPI with general kcrypto enctypes, it's just fine

Yes, 0..32767 is more than we're likely to need; for that matter, I
hope that 0..127 is more than enough.  I just want the interpretation
of the other 2**15 values to be thought about, not written up some
random way because no one bothered to think about it.

Ken

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 3 Sep 2003 22:15:50 -0700

Ken Raeburn wrote:

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

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

I was trying to allow EC for data alignments as suggested by Sam.  

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

I did not want to use padding here and I ran of words. I chose to define
the term "garbage" first, and then used it here.

With that, can you think of some better presentations?

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

Should the use of 2's compliment encoding expressed in big endian order
be sufficient?  Nicolas, you and I did not think it was necessary to
rotate left at this point however.

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

To me, less error conditions -> less branches -> better performance.  I
think the modular math is implied by draft -01.  We can change it if you
object it strongly, and in that case we can add text to describe the
error conditions.

Thanks. Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 2:56 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:
> Is it possible to change the text above to fit with existing
> implementations?

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.

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

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

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

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.

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

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.

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

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

Ken

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 4 Sep 2003 00:16:26 -0700

>> >       20..23  Flags   Bit vector of context-establishment flags, 
>> >                       as defined next. The resulting bit vector is

>> >                       encoded into bytes 20..23 in little-endian
form. 

>> In this section and the next, there are lots of descriptions of bit
>> order or byte order, bit vectors and integers, bit numbers, etc.  I
>> think I can make a case that they're not entirely consistent.

>> RFC 1964 was kind of unclear on this too.

>> Storing a bit vector in little-endian order suggests to me that bit 0
>> of the vector should be first.  But bit 0 is the most significant bit
>>(section 7.1.1), so I guess bit 31 comes first.  Converting bit
>> strings to octets normally involves breaking them into groups of 8,
>> and in each set of 8, generally the first becomes the "high" bit, but
>> that doesn't seem to be the case here.

>> If I get this mostly straight, GSS_C_MUTUAL_FLAG, with a value of 2,
>> corresponds to bit 30, and would be expressed in the flags field as:

>>  02 00 00 00

>> right?

>> And you can make the bit vector make sense if you express each byte
in
>> little-endian bit order:

 >> LSB=7  MSB=0 (octet)
>>  v      v
>>  01000000 00000000 00000000 00000000
>>  ^ bit 31                    bit 0 ^ (bit vector)

>> but that doesn't seem very natural.

>> It shouldn't be this hard to figure out.  I suggest dropping the byte
>> order description in 7.1, and putting a more useful diagram into
>> 7.1.1.  If you want, I'll try to write up that description myself.

>> We have an interesting mix of big-endian and little-endian values in
>> this mechanism, but I think most of the non-bit-vector cases are
>> pretty clear.

The root cause of the confusions here is mixing bit vectors with
endian-ness.  It is unclear to me if the most significant bit is defined
for a bit vector or if there is a value associated with a bit in the bit
vector. I would suggest dropping the bit-vector.  Here is the new text:

  The format of the authenticator checksum field is as follows.
   
     Byte    Name      Description
    -----------------------------------------------------------------
     0..3    Lgth    Number of bytes in Bnd field;
                     Currently contains hex 10 00 00 00
                     (16, represented in little-endian form)
     4..19   Bnd     MD5 hash of channel bindings, taken over all 
                     non-null components of bindings, in order 
                     of declaration.  Integer fields within channel 
                     bindings are represented in little-endian order 
                     for the purposes of the MD5 calculation.
     20..23  Flags   Four-byte context-establishment flags in little-
                     endian form as defined in section 7.1.1.      
     24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
     26..27  Dlgth   The length of the Deleg field [optional]
     28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]
 
         [we need to get input on how to allow additional data for     
          extensions.  Nicolas will post some text for this.  If that is
the 
          case, do we need to change the checksum type?]

   7.1.1. Flags Field

   The checksum flags are used to convey service options or extension

   negotiation information.  The bits in the Flags field are allocated
as  
   follows (least significant bit is bit 0):

     Bit         Name          Description                 
   ----------------------------------------------------
     0..15     Standard      Context establishment flags
     16..19    Optional      Non-Critical extension flags
     20..31    Mandatory     Critical extension flags

Can you improve it further from here?

>> Section 7.1.1:
>> >       Bit         Name          Description                  
>> >     ---------------------------------------------------- 
>> >       0..11     Mandatory     Critical extension flags 
>> >       12..15    Optional      Non-critical extension flags 
>> >       16..31    Standard      Context establishment flags 

>> I'm not sure I like this.  RFC 2744 doesn't provide for a distinction
>> between mandatory and optional flag bits to be specified in the
future
>> at the API level, and the Kerberos mechanism so far has been using
>> values consistent with the API.  So if a v3 GSSAPI defines new
>> optional flags, and they happen to land in the "mandatory" field
>> above, we would need to specify a new encoding to pass such flags
>> across.

This assumes that req_flags for gss_init_sec_context will not land into
the mandatory field, and if that does happen, a new encoding and
token_id will be needed.  Also note that the domain for req_flags does
not have to match with that of the Flags value here.

>> And, in any case, what do these "standard" flags mean, anyways?

Short for "context establishment flags"

>> What do you mean by "acceptor MUST return" here?  Some particular
>> function on the acceptor side should return this error?  
>> Is it
>> compatible with RFC 2743 or 2744 specifications for that function?

GSS_S_FAILURE with an explanatory minor code seems to match better with
2743/2744.

>> >    All existing context establishment flags are non-critical, and
it is 
>> >    possible that a new context establishment flag can be added as a

>> >    critical flag. 

>> I'm not sure that's true.  At least, I don't know if the v2 API
allows
>> for it.

I have some doubt on this one too.  Most of the above was added based on
email from Nicolas.

>> > 8.2. Flags Field 

>> Clarify the bit order.  Does bit 0 correspond to 0x80 or 0x01?

>> If I got 7.1 right, and if 8.2 uses the same scheme, it would be
0x80.

Fixed in -02

>> >    The rest of available bits are reserved for future use. 

>> And?  Presumably they should always be set to zero by the sender for
>> now.  If they're set, should the receiver ignore them or reject the
>> message?

The receiver should reject unknown flags; this is now fixed in -02.

Thanks. larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 7:12 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Sam Hartman; Nicolas Williams; JK Jaganathan
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

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

>       20..23  Flags   Bit vector of context-establishment flags, 
>                       as defined next. The resulting bit vector is  
>                       encoded into bytes 20..23 in little-endian form.

In this section and the next, there are lots of descriptions of bit
order or byte order, bit vectors and integers, bit numbers, etc.  I
think I can make a case that they're not entirely consistent.

RFC 1964 was kind of unclear on this too.

Storing a bit vector in little-endian order suggests to me that bit 0
of the vector should be first.  But bit 0 is the most significant bit
(section 7.1.1), so I guess bit 31 comes first.  Converting bit
strings to octets normally involves breaking them into groups of 8,
and in each set of 8, generally the first becomes the "high" bit, but
that doesn't seem to be the case here.

If I get this mostly straight, GSS_C_MUTUAL_FLAG, with a value of 2,
corresponds to bit 30, and would be expressed in the flags field as:

  02 00 00 00

right?

And you can make the bit vector make sense if you express each byte in
little-endian bit order:

 LSB=7  MSB=0 (octet)
  v      v
  01000000 00000000 00000000 00000000
  ^ bit 31                    bit 0 ^ (bit vector)

but that doesn't seem very natural.

It shouldn't be this hard to figure out.  I suggest dropping the byte
order description in 7.1, and putting a more useful diagram into
7.1.1.  If you want, I'll try to write up that description myself.

We have an interesting mix of big-endian and little-endian values in
this mechanism, but I think most of the non-bit-vector cases are
pretty clear.

Section 7.1.1:
>       Bit         Name          Description                  
>     ---------------------------------------------------- 
>       0..11     Mandatory     Critical extension flags 
>       12..15    Optional      Non-critical extension flags 
>       16..31    Standard      Context establishment flags 

I'm not sure I like this.  RFC 2744 doesn't provide for a distinction
between mandatory and optional flag bits to be specified in the future
at the API level, and the Kerberos mechanism so far has been using
values consistent with the API.  So if a v3 GSSAPI defines new
optional flags, and they happen to land in the "mandatory" field
above, we would need to specify a new encoding to pass such flags
across.

And, in any case, what do these "standard" flags mean, anyways?

>    An extension or context establishment flag can either be critical
or 
>    non-critical.  When the context initiator desires a particular 
>    extension or context establishment flag (either critical or non-
>    critical) it sets the appropriate checksum flag.  The context 
>    acceptor MUST ignore unsupported non-critical extensions or flags
in 
>    the initiator's context token (i.e., acceptors MUST NOT return an 
>    error just because there were unsupported non-critical extensions
or 
>    flags in the initiator's token).  The acceptor MUST return 
>    GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical 
>    extensions or flags in the initiator's context token. 

What do you mean by "acceptor MUST return" here?  Some particular
function on the acceptor side should return this error?  Is it
compatible with RFC 2743 or 2744 specifications for that function?

>    All existing context establishment flags are non-critical, and it
is 
>    possible that a new context establishment flag can be added as a 
>    critical flag. 

I'm not sure that's true.  At least, I don't know if the v2 API allows
for it.

> 8.2. Flags Field 

Clarify the bit order.  Does bit 0 correspond to 0x80 or 0x01?

If I got 7.1 right, and if 8.2 uses the same scheme, it would be 0x80.

>    The rest of available bits are reserved for future use. 

And?  Presumably they should always be set to zero by the sender for
now.  If they're set, should the receiver ignore them or reject the
message?

Ken