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

From: Martin Rex <[email-masked]>
Date: Thu, 6 Nov 2003 19:29:36 +0100 (MET)

Liqiang wrote:
> 
> Nicolas Williams wrote:
> >> It is too late to reject the context, but the acceptor could reject
> all
> >> per-msg tokens that don't use the acceptor asserted subkey.  I
> mis-wrote.
> 
> When the initiator says "prot_ready", it can not be authoritative,
> because the authentication/context-establishment may eventually fail.
> With this extension, it goes one step further, namely the
> context-establishment may succeed, but message protection may fail.
> This might be obvious, but I want to spell it out here to make sure such
> behavior is understood and acceptable.

Whenever one side fails to follow the protocol spec then the other
side should be permitted to abort with an error.

However, as has been described, the existence of prot_ready might
make it impossible for the acceptor to know if and when the initiator
should no longer be using the subkey that the initiator created and
presented in the authenticator.

As long as acceptor has no reliable proof that the initiator must
know the acceptor-asserted subkey and that all further messages
must have been protected after the initiator became aware of the
acceptor-asserted subkey, the acceptor must be prohibited from
failing message unprotection based on a policy decision.
(failing message (un)protection when the security context expires
 is still permitted, of course).

Neither rfc-1964 nor CFX provide any such proof for the acceptor.
An application might draw conclusions at some point from the contents
of the protected messages, but this meta-information is *NOT*
available to the gssapi mechanism.

One conceivable approach could be to reflect whether the initiator-supplied
subkey or the acceptor-supplied subkey is used via specific bits
the QOP output value in CFX -- an application could look at the QOP
value returned from message unprotection and then consciously decide
whether to continue communication or abort.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 14:48:02 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> However, as has been described, the existence of
    Martin> prot_ready might make it impossible for the acceptor to
    Martin> know if and when the initiator should no longer be using
    Martin> the subkey that the initiator created and presented in the
    Martin> authenticator.

    Martin> As long as acceptor has no reliable proof that the
    Martin> initiator must know the acceptor-asserted subkey and that
    Martin> all further messages must have been protected after the
    Martin> initiator became aware of the acceptor-asserted subkey,
    Martin> the acceptor must be prohibited from failing message
    Martin> unprotection based on a policy decision.  (failing message
    Martin> (un)protection when the security context expires is still
    Martin> permitted, of course).

We all agree with this statement.

However we believe this statement is not inconsistent with client MUST
use acceptor-asserted subkey .  We cannot check at the acceptor that
client implementations are correct, but if we have sufficient security
or interoperability justification, we can mandate that once the client
has received the acceptor-asserted subkey, it MUST use it.

There are several situations in which the client will never receive
the subkey, including the single-token case.

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 Nov 2003 22:30:35 +0100 (MET)

> has received the acceptor-asserted subkey, it MUST use it.

That's OK as an requirement for the initiator for the new CFX enctypes,
but it cannot be changed for the rfc-1964 defined ones -- which btw.
are still not listed in gssapi-cfx-03 although I think they should be.
(although not in rfc-1964 this may also apply to enctypes that use
 rfc-1964 semantics like RC4-HMAC(NT), I assume.)

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Nov 2003 16:46:45 -0500

Martin> Sam Hartman wrote:
    >>  However we believe this statement is not inconsistent with
    >> client MUST use acceptor-asserted subkey .  We cannot check at
    >> the acceptor that client implementations are correct, but if we
    >> have sufficient security or interoperability justification, we
    >> can mandate that once the client has received the
    >> acceptor-asserted subkey, it MUST use it.

    Martin> That's OK as an requirement for the initiator for the new
    Martin> CFX enctypes, but it cannot be changed for the rfc-1964
    Martin> defined ones -- 

Agreed.

    Martin> which btw.  are still not listed in
    Martin> gssapi-cfx-03 although I think they should be.  (although
    Martin> not in rfc-1964 this may also apply to enctypes that use
    Martin> rfc-1964 semantics like RC4-HMAC(NT), I assume.)

OK.  I know we are going to call out the list of old enctypes in
clarifications; people also seemed to want this in GSSAPI-CFX and no
one objected.