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

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

Nicolas Williams wrote:

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

Can we defer these till we have worked out the details for extensions?
We can just fix the text for now.

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: Nicolas Williams <[email-masked]>
Date: Wed, 3 Sep 2003 09:28:49 -0700

> We can just fix the text for now.

I think we need to decide whether we want to do this now, or wait for
Kerberos extensions to give us the right typed holes for this in the
Authenticator and AP-REP encpart, and then update the mech to describe
negotiation of GSS-APIv3 features (rekeying, PFS, GGF's proposed
extensions, etc...) using these typed holes.

IIRC Sam preferred to do this now.  Right now I can go either way.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Sep 2003 18:43:03 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Sep 02, 2003 at 10:55:16PM -0700, Liqiang(Larry)
    Nicolas> Zhu wrote:
    >> Nicolas Williams wrote:
    >> 
    >> >> 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.
    >> 
    >> Can we defer these till we have worked out the details for
    >> extensions?  We can just fix the text for now.

    Nicolas> I think we need to decide whether we want to do this now,
    Nicolas> or wait for Kerberos extensions to give us the right
    Nicolas> typed holes for this in the Authenticator and AP-REP
    Nicolas> encpart, and then update the mech to describe negotiation
    Nicolas> of GSS-APIv3 features (rekeying, PFS, GGF's proposed
    Nicolas> extensions, etc...) using these typed holes.

    Nicolas> IIRC Sam preferred to do this now.  Right now I can go
    Nicolas> either way.

I prefer to do it now but am OK continuning to use checksum type
0x8003.