Subject: AD review: draft-ietf-kitten-2478bis-02

From: Sam Hartman <[email-masked]>
Date: Sun, 12 Dec 2004 20:38:31 -0500 (EST)

Between a time a document is submitted for publication and the time
the IETF last call is issued, the AD responsible for the document
reviews the specification and provides the AD's comments.  The authors
of this specification are interested in seeing it move relatively
quickly and I had some extra time so I've pushed up my review of the
document to happen during the WG last call.

The following issues must be addressed before the IETF last call can
be issued.  As always, the chair judges consensus on how the working
group wants to respond to the issue.  Responses can include accepting
proposed changes or a response arguing that the comment should be
dropped for some reason.

abstract: Suggested new text: If the available security mechanisms
provide for integrity protection, then the negotiation is protected
against an attacker forcing the selection of a mechanism not desired
by the peers.  This mechanism replaces RFC 2478 in order to fix
defects in that specification and to describe how to interoperate with
actual implementations of that specification.

section 1:
old:
   If per-message integrity services are available on the established
   mechanism security context, then the peers can exchange MIC tokens to
   ensure that the mechanism list was not tampered with.  This MIC token
   exchange is OPTIONAL if the selected mechanism is the most preferred
   choice of both peers (see Section 5).

new :
   If per-message integrity services are available on the established
   mechanism security context, then the negotiation is protected to
ensure that the mechanism list has not been modified.  In cases where
an attacker could have materially influenced the negotiation, peers
exchange message integrity code (MIC) tokens to confirm the mechanism
list has not been modified.  If no action of an attacker could have
materially modified the outcome of the negotiation, the exchange of
MIC tokens is optional.  Allowing MIC tokens to be optional in this
case provides interoperability with existing implementations while
still protecting the negotiation.  This interoperability comes at the
cost of increased complexity. 

(Perhaps we still want a reference to section 5)

The document claims that using the optimistic token you can avoid
additional round-trips.  I'm not sure this is true in the fullness of
time if people start using feature oids per the extensibility section.

    SPNEGO relies the concepts developed in the GSS-API specification
s/relies/relies on/

Section 3:

The text seems to imply that the SPNEGO implementation uses another
mechanism's credentials.  This is only sort of true and I'm concerned
the current text could confuse readers.  It seems fairly clear from
RFC 2743 that SPNEGO has its own credentials.  These credentials may
(and almost certainly are) be composed of credentials for other
mechanisms.  However the set of mechanisms in the gss credentials
exposed to the application does not influence what mechanisms SPNEGO
can negotiate.    Do others think the text in section 3 is confusing
on this issue?

    Lastly, MIC tokens MAY be exchanged to ensure the authenticity of the
    mechanism list received by the target.
s/MAY/may/
That's a non-normative  may.  If it is MAY, then it means
that implementations optionally can exchange these tokens.  Whether
that's true depends on rules in section 5.

    the prot_ready_state [RFC2743] will be false even if the underlying
    mechanism would return true natively.
s/will/MUST/

       (III) Otherwise, GSS_Accept_sec_conext() indicates GSS_S_COMPLETE
Fix typo

Section 4:

A publication request for this document should be accompanied by a
true assertion that the ASN.1 module has been validated.  Please
include the name of the person doing the validation and the tool used.

    In this negotiation model, each OID represents one GSS-API mechanism
    or one variant (see Section 6) of it according to [RFC2743].
I see nothing in section 6 that speaks to variants.

	  This field is REQUIRED in the first reply from the target, and
	  it is OPTIONAL thereafter.

What happens if it is absent?

Section 5:

    It is assumed that per-message integrity services are available on
    the established mechanism context in the following procedure for
    processing MIC tokens of the initiator's mechanism list.
This text is redundant.

       Acceptors that wish to be compatible with legacy Windows SPNEGO
       implementations as described in Appendix B shall not generate a
       mechlistMIC token when the MIC token exchange is not required.
I'd rather not have a 2119 SHALL subordinate to a "wish to" clause
suggest s/SHALL/should/
    c) In the case that the chosen mechanism uses an odd number of
       mechanism tokens (namely the initiator sends the last mechanism
       token), the initiator does the following when emitting the
       negotiation message containing the last mechanism token: if the
       negResult state was request_mic in the first reply from the

Isn't the mechlistmic also required if a mechanism other than the
initiator's first choice chosen?

Same comment about SHALL as above.

Section 10:

RFC 2478 cannot be a normative reference if this spec replaces it.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Dec 2004 04:53:27 -0600

> I'd rather not have a 2119 SHALL subordinate to a "wish to" clause

This seems like a matter of wording, and I do think that RFC2119
verbiage is needed here as this does involve interop with a widely
deployed implementation.  BTW, what is "legacy" in this case?  Should we
care?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Dec 2004 09:41:23 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Sun, Dec 12, 2004 at 08:38:31PM -0500, Sam Hartman
    Nicolas> wrote:
    >> I'd rather not have a 2119 SHALL subordinate to a "wish to"
    >> clause suggest s/SHALL/should/

    Nicolas> This seems like a matter of wording, and I do think that
    Nicolas> RFC2119 verbiage is needed here as this does involve
    Nicolas> interop with a widely deployed implementation.  BTW, what
    Nicolas> is "legacy" in this case?  Should we care?

Propose text.  Based on the timing I'd rather assume that any change
we agree to will be integrated after ietf last call (probably in an
rfc editor note) rather than before ietf lc.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Dec 2004 10:22:45 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Nicolas> wrote:
    >>> Acceptors that wish to be compatible with legacy Windows
    >>> SPNEGO implementations as described in Appendix B shall not
    >>> generate a mechlistMIC token when the MIC token exchange is
    >>> not required.  I'd rather not have a 2119 SHALL subordinate to
    >>> a "wish to" clause suggest s/SHALL/should/

    Sam> Propose text.  Based on the timing I'd rather assume that any
    Sam> change we agree to will be integrated after ietf last call
    Sam> (probably in an rfc editor note) rather than before ietf lc.

Actually, I think timing is less of an issue now given Nico's other
comments.

--Sam