Subject: Re: SASL GSSAPI to IETF Last Call

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 17:15:48 -0700

Alexey Melnikov wrote:
> GSSAPI-KERBEROS probably list only one OID (new one).

GSSAPI-KERBEROS lists both OIDs.

> > I had (and have) no intent to allow for extensibility here.  You'll note
> > that the corresponding client-to-server message is not extensible.
> 
> Good.

I added a parentetical remark to the document.  I hope it doesn't make
things too confusing.

> Do you want to say anything about canceling GSSAPI exchange (I mean what peer
> should do if it receives cancellation request)?

Not particularly.  This is adequately covered by the GSSAPI spec.  The
description of the exchange is complicated enough as it is, I don't want
to have important interoperability and security points buried by obvious
housekeeping details.

> You are right. Can you add the following sentence than:
> "Client willing to perform mutual authentication MUST pass GSS_C_MUTUAL_FLAG flag
> to gss_init_sec_context call".

That particular statement is vacuous.  I added statements requiring the
client to pass additional flags corresponding to the security layers it
will be requesting.

> Actually you already wrote the paragraph that answer my question. I suggest you
> add something like the following:
> "When authentication exchange is complete both peers SHOULD check whether the
> required protection level was achieved."

I added something to this effect to the document.

> After looking through GSSAPI spec: GSS_C_REPLAY_FLAG & GSS_C_SEQUENCE_FLAG are
> always discussed together, but a particular implementation may decide to implement
> any one of them (or both).
> I suggest that both client and server specify both flags when calling
> gss_init_sec_context/gss_accept_sec_context.

I don't see the need to mandate replay_det_req_flag.

> I think there is a consensus that GSS_C_NO_CHANNEL_BINDINGS should be used.
> Mark Crispin also agrees with that.

Added.

> I suggest you mention that GSS_Wrap_size_limit can be
> used (if available in GSSAPI implementation) to determine what cleartext buffer
> size sender should use in order to produce ciphertext buffer not bigger than
> receiver's maximal buffer.

Added.

Revised document submitted to the I-D editor.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2001 20:34:43 -0600

> GSSAPI-KERBEROS lists both OIDs.

Ok.

> [skipped]

A sentence saying that "other flags MAY be specified" will make me happy.

> [skipped]

> I don't see the need to mandate replay_det_req_flag.

Because some GSSAPI implementations support only replay detection, but not sequencing.

Alexey

---

From: John Gardiner Myers <[email-masked]>
Date: Tue, 17 Apr 2001 17:15:48 -0700

Added.

Added.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Apr 2001 20:34:43 -0600

Ok.

Alexey