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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 10 Oct 2003 14:09:35 -0700

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 think the text in the draft for this is sufficiently strong and clear.

Larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 8:21 AM
To: Liqiang(Larry) Zhu; Ken Raeburn; [email-masked]
Cc: Douglas E. Engert
Subject: RE: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt
 
On Friday, October 10, 2003 01:43:00 -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> Ken Raeburn wrote:
>
>>> Section 1:
>
>>> Next to last paragraph: I don't think this is a great description.
>>> How would you classify RC4 based on this?  An I-D came out, but no
> RFC
>>> yet.  I would hope that if an RFC came out now, it would be in terms
>>> of a kcrypto profile.  So, if you get an RC4 session key, should you
>>> assume support for CFX, or the Microsoft RC4 mechanism extension?
>>> (And how about 3DES?  The write-up I did on MIT's extension never
>>> became an RFC.)  Maybe better would be to list the types that are
not
>>> supported this way.
>
> Jeff brought up this point too. The clarification really should
> enumerate all of the enctypes which are not "newer".
>
> I am now less optimistic for putting the list into the clarifications.
> Should we go ahead adding the list here?  Because whether an enctype
is
> "newer or not" is also tied to the decision whether to use ETYPE_INFO2
> or ETYPE_INFO, I will be a bit sadden if we end up defining the
> not-newer enctypes in this draft.
>
> I want to bring this up to the attention of Doug and he would know the
> IESG-last-call status for the clarifications.

Yes; I think this is worth fixing before clarifications is published as
an 
RFC.  The current wording is too ambiguous; it depends on the reader to 
determine in what order certain specs were issued, which may not
correspond 
to RFC numbers, and/or to make a determination as to whether particular 
specs were issued "simultaneously".

Interestingly, Ken, you've called out all the execption cases I know
about. 
The only "older" enctypes AFAIK are the existing DES, 3DES, and RC4 
enctypes, some of which are not described in RFC's.

The gssapi-cfx document, then, should refer to the list in [KRBCLAR].

> required
>>> to start using it on receipt, under what circumstances should/may
the
>>> acceptor start flagging as errors tokens received without the
>>> AcceptorSubkey flag set?
>
> It should not be enforced by the acceptor or the initiator, but rather
> it is enforced by the sender and not enforceable by the receiver. The
> text here serves two purposes:
>
> 1) it tells implementers that acceptor-subkey always wins, this was
not
> clearly stated before.
> 2) it allows implementations that do not support prot_ready to discard
> initiator-asserted-subkey.

I don't think this is good enough.  If prot_ready is supported, then an 
initiator may construct a per-message token using an initiator-subkey, 
before it has received the AP-REP from the acceptor.  For prot_ready to
be 
useful, the acceptor must be willing and able to process such a message.

However, 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; we have initiator-does-whatever-he-wants.

> I do not think prot_ready is that useful after all.

It may save round trips in some application protocols.  That's often 
beneficial.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ken
Raeburn
> Sent: Thursday, October 09, 2003 7:09 PM
> To: [email-masked]
> Subject: comments on draft-ietf-krb-wg-gssapi-cfx-02.txt

> Section 6:
>
> What does "use of Kerberos Version 5 extensions" mean?  I think I know
> what you mean by it, but the spec should be useful to an implementor
> (now, or 10 years in the future) who isn't keeping tabs on the working
> group discussions.

Well, you can't actually refer to kerberos-extensions without waiting
for 
it.  Fortunately, you don't have to:

"use of a version of Kerberos later than Kerberos Version 5
Specification 
2".

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 10 Oct 2003 17:58:38 -0400

> the receiver can not really achieve anything by rejecting such messages.

Then this text is incorrect:

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

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

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 10 Oct 2003 18:10:30 -0400

"Liqiang\(Larry\) Zhu" <[email-masked]> writes:
>   A clever receiver can reject a message projected with
> acceptor-asserted-subkey,

This brings me back to my question: When?  Don't just say, "he has to
be clever".

The only obvious case that comes to mind is tokens with sequence
numbers following those of other tokens for which the acceptor's
subkey was used.

I think Jeff's right.  Unless it's actually enforceable, the MUST
seems a bit too strong.

Ken

---

From: Martin Rex <[email-masked]>
Date: Sat, 11 Oct 2003 00:15:59 +0200 (MET DST)

Liqiang wrote:
> >> have acceptor-subkey-wins;
> 
                                    ^^^^^^^^^^^^^^
> 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: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 16:01:46 -0500

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