Subject: RE: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 11 Oct 2003 01:56:32 -0700

Martin Rex wrote:
>> Please explain how the receiver gssapi mechanism can know for sure,

Use the sequence number as the hint as Ken suggested, if you see a
message with number X marked as "AcceptorSubkey", you probably know for
sure message X+1 should also be marked the same way as well.

Essentially in this approach we still rely on the sender to well behave.

[email-masked] wrote:

>> "subsequent messages MUST use this subkey" is too strong -- the use
of 
>> the acceptor subkey in this case is not necessary for
interoperability or 
>> security; in fact, there is no way that a failure of the initiator to

>> obey this rule can be detected by the acceptor.  Unless, of course,
the >> acceptor assumes the initiator will not make any per-message
tokens 
>> before the context is fully established.  But the only way to
guarantee 
>> that is for the mechanism not to support prot_ready at all, and I
think 
>> the wind is currently blowing in favor of keeping prot_ready.

>> IMHO, the use of the acceptor subkey ought to be a SHOULD for tokens
sent 
>> by the initiator, and a MUST for tokens sent by the acceptor.
Further, >> if the acceptor asserts a subkey, the initiator ought to be
REQUIRED to >> reject tokens from the acceptor which do not use it.

There could be un-processed messages that are protected with
initiator-asserted-subkey when the initiator receives the
acceptor-asserted-subkey. It is equally hard for either the initiator or
acceptor to draw an exact line when to reject messages: the receiver can
not tell if the sender started to use the acceptor-asserted-subkey as
soon as this acceptor-asserted-subkey is established, where the sender
can be either the initiator or the acceptor, correct?

Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 3:16 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

Liqiang wrote:
> 
> Jeffrey Hutzelman wrote:
> >> if the acceptor does not at some point start rejecting per-message 
> >> tokens which do not use the acceptor-subkey, then we don't really
> >> have acceptor-subkey-wins;
> 
> A correctly-implemented sender will use the acceptor-subkey as soon as
> possible. A clever receiver can reject a message projected with
> initiator-asserted-subkey when it knows for sure it is supposed to use
                                    ^^^^^^^^^^^^^^
> acceptor-asserted-subkey, but such corrective action is deemed
optional:
> the receiver can not really achieve anything by rejecting such
messages.

I'm sorry, but I absolutely don't see how.

Please explain how the receiver gssapi mechanism can know for sure,
(not the application caller using meta-knowledge and non-standard apis).

(Guessing that the initiators's implementation doesn't support
 prot_ready from what the bits in the AP_REQ looked like is
 not a valid answer).

> 
> I think the text in the draft for this is sufficiently strong and
clear.

This particular item is not the slighest clear to me.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 13 Oct 2003 16:42:01 +0200 (MET DST)

> sure message X+1 should also be marked the same way as well.

I thought that sequence numbers where direction specific and independent,
i.e. each sender chooses the initial sequence number.  So the acceptor
cannot tell which incoming message should have been using the
Acceptor Subkey since it has no feedback whatsoever when the initiator
has processed the final context establishment token (in case the
initiator's implementation supports prot_ready).

> Essentially in this approach we still rely on the sender to well behave.

"rely on the sender" can be "recommended" at best.

> can be either the initiator or the acceptor, correct?

Well, if the acceptor asserts a subkey, then it should only ever
send messages protected under its own subkey and never messages
protected under the original initiator's subkey on this
security context.

In case a security contexts enforces sequenced messages, then
the decision should be easy: once a message protected under the new
subkey has been received, no message with the new subkey should be
accepted anymore.

For security contexts that DO NOT enforce sequenced messages it
might difficult to decide.  One could use the sequence number
of the first protected message that arrives with the new subkey,
so that no message with a sequence number higher than the
sequence number of the first message received under the new
subkey should be allowed with the old subkey, one just has
to keep in mind that the first message received under the
subkey is not necessarily the first message created under
the new subkey. I.e. after receiving the first message
under the new subkey the acceptor might receive messages
with a lower sequence number protected under the old
subkey but also under the new subkey.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Oct 2003 08:41:08 -0700

> protected under the original initiator's subkey on this

Correct.

> subkey has been received, no message with the new subkey should be
                                                ^^^
						I think you meant "old."
> accepted anymore.

Yup.  Well, "... no message should be accepted with the old key but
sequence number larger than the first per-msg token protected with the
new subkey."

> subkey but also under the new subkey.

One possible answer, picking up where you left off, is that if the
initiator [requests mutual auth and] does not request oos/replay
detection then the context will not be prot_ready until it is fully
established.

If we could somehow sequence prot_ready, pre-full-establishment per-msg
tokens but not post-full-establishment per-msg tokens that would be a
fine way to handle this - but that would violate rfc2743/4.

BTW, ONC RPC w/ RPCSEC_GSS is one application that requires the non-use
of out-of-sequence/replay detection - but it also doesn't use
prot_ready.  I do think, though, that it would be alright to update
RPCSEC_GSS to allow the use of oos/replay detection, however, it is a
small performance boost not to use oos/replay detection in ONC RPC apps
in that there's one fewer lock to wait for/lock/unclock.  But I digress.

Cheers,

Nico
--