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

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 13 Dec 2004 01:00:49 -0800

Sam wrote:
 
> 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.

This looks good, but I adjusted it slightly to exclude security contexts
that do not support integrity protection.

   If per-message integrity services are available on the established
   mechanism context, 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)

Agreed. It is now in -03 with 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.

It is not needed here and it is removed now.

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

Fixed

> 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?

It was meant to emphasize that the list should not contains mechanisms
that the initiator does not have credentials for.

New text

   The first negotiation token sent by the initiator contains an ordered
   list of mechanisms (in decreasing preference order, favorite
   mechanism first), and optionally the initial mechanism token for the
   preferred mechanism of the initiator (i.e., the first in the list).
   (Note that the list MUST NOT contain mechanisms for which the client
   does not have appropriate credentials.)

Is this a bit clearer?

>    Lastly, MIC tokens MAY be exchanged to ensure the authenticity of
the
>    mechanism list received by the target.
> s/MAY/may/

Fixed

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

Fixed

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

Larry Zhu, Microsoft ASN.1 Compiler V1.0.

I will also ask Luke to post which tool he 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.

Fixed

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

> What happens if it is absent?

Fixed. GSS_Init_sec_context() should indicate GSS_S_DEFECTIVE_TOKEN.

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

Agreed.

>       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/

Fixed

>    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?

Yes, but the acceptor must send reqest_mic in that case too

> Same comment about SHALL as above.

Fixed

> Section 10:

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

Moved to informative references.

For your convenience, I also attached the full version that should
contain all these changes.

Thanks,

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Sunday, December 12, 2004 5:39 PM
To: [email-masked]
Subject: AD review: draft-ietf-kitten-2478bis-02

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
_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Dec 2004 08:45:27 -0500

>>>>> "Larry" == Liqiang(Larry) Zhu <[email-masked]> writes:
    Larry> It was meant to emphasize that the list should not contains
    Larry> mechanisms that the initiator does not have credentials
    Larry> for.

    Larry> New text

    Larry>    The first negotiation token sent by the initiator
    Larry> contains an ordered list of mechanisms (in decreasing
    Larry> preference order, favorite mechanism first), and optionally
    Larry> the initial mechanism token for the preferred mechanism of
    Larry> the initiator (i.e., the first in the list).  (Note that
    Larry> the list MUST NOT contain mechanisms for which the client
    Larry> does not have appropriate credentials.)

I believe this is more clear but I believe it is wrong.  Let's say I
get credentials for SPNEGO and then add credentials for Kerberos to my
credentials.  If I then try and initiate a context, and the set of
mechanisms SPNEGO negotiates includes SPKM by default, it is
reasonable for me to end up with a SPKM context.  The actual SPKM
credentials used come from inside the SPNEGO credentials.

    Larry> Is this a bit clearer?

    >> What happens if it is absent?

    Larry> Fixed. GSS_Init_sec_context() should indicate
    Larry> GSS_S_DEFECTIVE_TOKEN.

I actually meant what value is assumed if it is absent in the second
and following messages?

>> initiator's first choice chosen?

    Larry> Yes, but the acceptor must send reqest_mic in that case too

Sure, but my point is that an client must require the MIC even if it
is talking to an incorrect implementation (read attacker) that does
not send request_mic when required.

Thanks much for the quick response.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 13 Dec 2004 16:42:02 -0500

> credentials used come from inside the SPNEGO credentials.

I'm not sure what you mean when you say "get credentials for SPNEGO".  Yes, 
from the RFC2743 point of view there is such a concept as SPNEGO 
credentials, but it's an abstraction for some set of underlying "real" 
credentials.  The requirement applies to that set of real credentials -- if 
your "SPNEGO credentials" don't include SPKM credentials, then it is not OK 
for SPNEGO to negotiate SPKM.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Dec 2004 22:00:58 +0100 (MET)

> for SPNEGO to negotiate SPKM.

Application-level "credentials management" that includes the SPNEGO
mechanism OID is un(der)specified, so you should *never* mix the SPNEGO
mechanism OID with any other mechanism OIDs when your (portable)
application calls gss_acquire_cred() or gss_add_cred().

Similarly, your SPNEGO should never return individual mechanism OIDs
when a SPNEGO credentials handle is queried for the mechanisms
through gss_inquire_cred() or as the result of gs

rfc2478 defines a GSS-API extension in Appendix A with two additional
function calls that should be used to manipulate the mechanism (OIDs)
to which an SPNEGO credentials handle refers.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Dec 2004 02:22:25 -0600

> for SPNEGO to negotiate SPKM.

"Get credentials for SPNEGO" -> e.g., call GSS_Add_cred() w/
desired_mech == SPNEGO's OID, or call GSS_Init_sec_context() w/
GSS_C_NO_CREDENTIAL and SPNEGO's OID as the mech, etc...

Note that it's possible to have a GSS credential with elements for
multiple mechanisms including one for SPNEGO which, in turn, may have an
internal reference to a GSS credential with elements for non-SPNEGO
mechanisms.

Think of a non-monolythic multi-mechanism mech glue layer.

The GSS_Set_neg_mechs() and GSS_Get_neg_mechs() functions are there to
provide applications with control over what mechanisms a SPNEGO
credential may have elements for.

Nico
--