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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 30 Oct 2003 13:18:51 -0800

Sam Hartman wrote:
>> I actually think it is required for security; I agree it is not
>> required for interoperability.

The acceptor MUST insist on the acceptor-asserted-subkey (the acceptor
knows if there is replay cache), but the initiator might already send
out messages protected with the initiator-subkey at that point. Thus I
do not think we can enforce it in a meaningful way. I have updated -03
with "SHOULD" instead.  I do not think the acceptor-asserted subkey
works well prot_ready. One possible solution is to use a different OID
for the acceptor-asserted subkey that will also turn off prot_ready
support for the initiator. 

Larry

-----Original Message-----
From: [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 1:02 PM
To: Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; Ken Raeburn; [email-masked]; Douglas E.
Engert
Subject: Re: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> Then this text is incorrect:

    Jeffrey> During context initiation, the acceptor MAY assert a
subkey, and if
    Jeffrey> so, subsequent messages MUST use this subkey as the
protocol key and
    Jeffrey> these messages MUST be flagged as "AcceptorSubkey" as
described in
    Jeffrey> section 4.2.2.

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

I actually think it is required for security; I agree it is not
required for interoperability.

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Oct 2003 23:42:10 +0100 (MET)

Nicolas Williams wrote:
> Larry wrote:
> >                         I do not think the acceptor-asserted subkey

different OID?  What is that supposed to mean?

An rfc1964 initiator will come along with a rfc-1964 context establishment
token containing the rfc-1964 OID.  There is no negotiation of mechanisms
at this point, either the acceptor is capable of rfc-1964 and accepts
the security context or the communication fails entirely and forever. 

As long as CFX retains the rfc-1964 mechanism OID, the support of
regular rfc-1964 is a MUST.

> 
> I disagree with this.  If the initiator uses prot_ready-before-complete
> the acceptor MUST use a replay cache or reject the context, else the
> acceptor MAY forego the use of a replay cache under very special
> circumstances.
> 
> I don't see any harm in the initiator being able to force the acceptor
> to use a replay cache; even w/o prot_ready some (many? most?) rfc1964
> acceptors have to use a replay cache anyways.

Yup, rfc1964 requires a replay cache and a Kerberos CFX mechanism
that doesn't implement a replay cache would (a) non-compliant
and (b) broken.

rfc1964 also defines a unidirectional authentication which uses a single
context level token from initiator to acceptor, and in that exchange
there is simply no possibility for the acceptor to assert a subkey.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 13:30:24 -0800

On Thu, Oct 30, 2003 at 01:26:56PM -0800, Nicolas Williams wrote:
> On Thu, Oct 30, 2003 at 01:18:51PM -0800, Liqiang(Larry) Zhu wrote:
> > Sam Hartman wrote:
> > with "SHOULD" instead.
> Seems reasonable and is necessary if we're to support prot_ready.

I take this back and accept Sam's position on this.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 16:26:54 -0500

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

    >>> required for interoperability.

    Liqiang(Larry)> The acceptor MUST insist on the acceptor-asserted-subkey (the acceptor
    Liqiang(Larry)> knows if there is replay cache), but the initiator might already send
    Liqiang(Larry)> out messages protected with the initiator-subkey at that point. Thus I
    Liqiang(Larry)> do not think we can enforce it in a meaningful way. I have updated -03
    Liqiang(Larry)> with "SHOULD" instead.  I do not think the acceptor-asserted subkey
    Liqiang(Larry)> works well prot_ready. One possible solution is to use a different OID
    Liqiang(Larry)> for the acceptor-asserted subkey that will also turn off prot_ready
    Liqiang(Larry)> support for the initiator. 

The question is whether it should be a MUST or a SHOULD, not whether
we can enforce it.  

It does not need to be checkable to be a MUST, it just needs to be a
security or interop requirement.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Oct 2003 13:26:56 -0800

Cheers,

Nico
--