Subject: SPNEGO-bis comments/questions

From: Simon Spero <[email-masked]>
Date: Wed, 29 Dec 2004 21:59:52 -0500

Hi - I've got a few comments on the current draft; most of them are 
pretty minor.

1)  [ Section 4.2.1 : negTokenInit ]
 
1.1)  Extension marker.
Is the extension marker in NegTokenInit really necessary?  If future 
implementations need extra fields, wouldn't it be better to  define a 
new type and use a different OID in the  initialContextToken?

1.2)  mechTypes.
MAY mechTypes contain the OID for SPNEGO?  (I'd say MUST NOT).

2)  [Section 4.2.1 : ContextFlags ]
  Since context flags are now deprecated, it would be a good idea to add 
a SIZE constraint on the BIT STRING. 
ContextFlags ::= BIT STRING {<blah>} (SIZE(7))

3) [Section 4.2.2 : negTokenResp ]
    Is the extension marker necessary? If it is, should there also be an 
extension marker in negState?

4) Add appendix D, with all the ASN.1 (and no page breaks/headers).
[attached]

5)  [Section 5 - mechListMIC ]
 5.1) "Most Preferred Mechanism". How does the acceptor know what the 
most preferred mechanism of the initiator is? 
What happens if Mallet deletes all offered mechanisms that support integ 
from the intial token? By (5) (b)(III), this will COMPLETE without 
signalling any error. 

 5.2) How can a generic implementation know ahead of time whether a 
mechanism supports integrity?   This is just a subset of the bigger 
problem of negotiating QOP/Strength, etc. 
   
Of course, since the only mechanism I care about is Kerberos, I can 
ignore the problem for now :)

6) SET OF is really annoying, especially if you're using DER or PER;  in 
this case,  it's not that bad since the SET's don't go over the wire, 
but  I still hate them anyway (LDAP is fetid with the buggers).  It's 
not like there aren't any other, er, creative uses of ASN.1 in GSSAPI 
already...

7)  The target should be allowed to  send a negTokenInit before exchange.
When using HTTP Negotiate authentication the target is usually the one 
to suggest doing GSSAPI.  If the server was allowed to supply a 
negTokenInit with its preferred mechanisms list, we can potentially save 
a round trip if the initiator would have guessed wrong.  Would this 
break any existing implementations?

8) SPNEGO is an anagram of SPONGE.

Simon
SPNEGOASNOneSpec {
          iso(1) identified-organization(3) dod(6) internet(1)
          security(5) mechanism(5) snego (2) modules(4) spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN

MechType ::= OBJECT IDENTIFIER
	-- OID represents each security mechanism as suggested by
	-- [RFC2743]

MechTypeList ::= SEQUENCE OF MechType

NegotiationToken ::= CHOICE {
	negTokenInit    [0] NegTokenInit,
	negTokenResp    [1] negTokenResp
}

NegTokenInit ::= SEQUENCE {
	mechTypes       [0] MechTypeList,
	reqFlags        [1] ContextFlags  OPTIONAL,
	-- maintained from RFC 2478 for backward compatibility,
	-- RECOMMENDED to be left out
	mechToken       [2] OCTET STRING  OPTIONAL,
	mechListMIC     [3] OCTET STRING  OPTIONAL,
	...
}

ContextFlags ::= BIT STRING {
	delegFlag       (0),
	mutualFlag      (1),
	replayFlag      (2),
	sequenceFlag    (3),
	anonFlag        (4),
	confFlag        (5),
	integFlag       (6)
}

NegTokenResp ::= SEQUENCE {
	negState       [0] ENUMERATED {
               accept_completed    (0),
               accept_incomplete   (1),
               reject              (2),
               request_mic         (3)
	}                                 OPTIONAL,
	-- REQUIRED in the first reply from the target
	supportedMech   [1] MechType      OPTIONAL,
	-- present only in the first reply from the target
	responseToken   [2] OCTET STRING  OPTIONAL,
	mechListMIC     [3] OCTET STRING  OPTIONAL,
	...
}

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Dec 2004 22:35:57 -0600

> new type and use a different OID in the  initialContextToken?

As there would be no way to negotiate a negotiation mechanism I'd answer
yes to the first question and no to the second.

> MAY mechTypes contain the OID for SPNEGO?  (I'd say MUST NOT).

Does it matter?  As long as it isn't selected... (and if it is I'm sure
implementors will quickly realize that that doesn't work!).

But yes, a note about recursion avoidance would be nice.

> ContextFlags ::= BIT STRING {<blah>} (SIZE(7))

Perhaps.  It would help reject malformed messages sooner, before
allocating large buffers for large context flags bit strings, but since
there can't really be a small constraint on the size of the mechanism
token octet strings I don't think it would make much difference.
Wyllys? Larry?

> extension marker in negState?

Yes to the first question (see above).

As to the second question, I made the same point earlier to Larry as I
recall.  IIRC Larry responded that in practice extension markers on that
enum wouldn't help as unknown values really must lead to failure.

> 4) Add appendix D, with all the ASN.1 (and no page breaks/headers).

Good point.

> most preferred mechanism of the initiator is? 

It's the first OID in the initiator's mechList.

> from the intial token? By (5) (b)(III), this will COMPLETE without 

There's a security consideration w.r.t. the initiator offering, and the
acceptor being willing to accept, mechanisms that offer no integrity
protection support.

> problem of negotiating QOP/Strength, etc. 

See

draft-williams-gssapi-stackable-pseudo-mechs-00.txt

which is probably expired -- I'll submit a new version soon, as a KITTEN
work item.

That I-D proposes interfaces for discovering mechanisms' attributes.

Without such an extension applications have to hardcode such
information.  For example, SSHv2 has support for using the GSS-API for
user and host authentication, and it has its own method for mechanism
negotiation, so it forbids the use of SPNEGO, but since
GSS_Indicate_mechs() is free to indicate support for SPNEGO what is an
SSHv2 implementation to do but to hardcode the OID of SPNEGO and filter
it out from the list of mechanisms for which it has credentials for the
relevant principal?

> ignore the problem for now :)

If your application hardcodes mechanism OIDs, yes.

> not like there aren't any other, er, creative uses of ASN.1 in GSSAPI 

No ASN.1 SET OF type is actually used in any SPNEGO messages or,
therefore, on the wire.

SET OF is only used in the generic description of the SPNEGO programming
interfaces, about which there was a long thread recently.

> break any existing implementations?

That would be a very different mechanism.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Dec 2004 00:06:48 -0500

>>>>> "Simon" == Simon Spero <[email-masked]> writes:

    Simon> Hi - I've got a few comments on the current draft; most of
    Simon> them are pretty minor.

Responding as an individual:

    Simon> 1) [ Section 4.2.1 : negTokenInit ] 1.1) Extension marker.
    Simon> Is the extension marker in NegTokenInit really necessary?
    Simon> If future implementations need extra fields, wouldn't it be
    Simon> better to define a new type and use a different OID in the
    Simon> initialContextToken?

No, there's really no way to negotiate the negotiation mechanism you
are using.  You want a way to send new fields that the receiver must
ignore.

    Simon> 1.2) mechTypes.  MAY mechTypes contain the OID for SPNEGO?
    Simon> (I'd say MUST NOT).

I agree, MUST NOT.

    Simon> 2) [Section 4.2.1 : ContextFlags ] Since context flags are
    Simon> now deprecated, it would be a good idea to add a SIZE
    Simon> constraint on the BIT STRING. ContextFlags ::= BIT STRING
    Simon> {<blah>} (SIZE(7))

Hmm.  I wonder if anyone gets minimal length of bitstrings wrong for
SPNEGO?

    Simon> 3) [Section 4.2.2 : negTokenResp ] Is the extension marker
    Simon> necessary? If it is, should there also be an extension
    Simon> marker in negState?

I think the question you should ask is whether adding the extension
marker is harmful.  Having an extension marker in negstate is fine,
provided that you implementations only to send extensions after
learning that the recipient supports them.

    Simon> 4) Add appendix D, with all the ASN.1 (and no page
    Simon> breaks/headers).  [attached]

You cannot have text without page breaks/headers in an RFC and
technically it is a violation of id-nits to do so in an
internet-draft.

    Simon> 5) [Section 5 - mechListMIC ] 5.1) "Most Preferred
    Simon> Mechanism". How does the acceptor know what the most
    Simon> preferred mechanism of the initiator is? 

It doesn't.  The procedure outlined insures that the initiator doesn't
return complete if a MIC is required and the most preferred mechanism
is not selected.

    Simon> What happens if
    Simon> Mallet deletes all offered mechanisms that support integ
    Simon> from the intial token? By (5) (b)(III), this will COMPLETE
    Simon> without signalling any error.

Yep, offering a mechanism without integrity means you are willing to
accept no integrity (and thus no protected negotiation)

    Simon>  5.2) How can a generic implementation know ahead of time
    Simon> whether a mechanism supports integrity?  This is just a
    Simon> subset of the bigger problem of negotiating QOP/Strength,
    Simon> etc.  Of course, since the only mechanism I care about is
    Simon> Kerberos, I can ignore the problem for now :)

Out of scope for this document; strictly speaking a SPNEGO You can
determine this after the context is established.  If you want to know
before say to decide what mechanisms to offer, current GSSAPI provides
no mechanism so you'll have to know the OIDs of some mechanisms that
support integrity.  This working group is chartered to solve that
problem too and Nico does have drafts in that space.

    Simon> 6) SET OF is really annoying, especially if you're using
    Simon> DER or PER; in this case, it's not that bad since the SET's
    Simon> don't go over the wire, but I still hate them anyway (LDAP
    Simon> is fetid with the buggers).  It's not like there aren't any
    Simon> other, er, creative uses of ASN.1 in GSSAPI already...

This is not an ASN.1 type; it is a GSSAPI type.

    Simon> 7) The target should be allowed to send a negTokenInit
    Simon> before exchange.  When using HTTP Negotiate authentication
    Simon> the target is usually the one to suggest doing GSSAPI.  If
    Simon> the server was allowed to supply a negTokenInit with its
    Simon> preferred mechanisms list, we can potentially save a round
    Simon> trip if the initiator would have guessed wrong.  Would this
    Simon> break any existing implementations?

GSSAPI always starts with an initiator (funny that).

    Simon> 8) SPNEGO is an anagram of SPONGE.

Good to know.

---

From: Simon Spero <[email-masked]>
Date: Thu, 30 Dec 2004 11:13:26 -0500

>are using.  You want a way to send new fields that the receiver must
The trouble with extension markers is that they can't be used for 
critical extensions, and those extensions are only labeled by tag.   
They're also not part of the MIC.   It might be better to reuse 
Extension(s) from PKIX.

>Hmm.  I wonder if anyone gets minimal length of bitstrings wrong for
Not so much getting the minimal length wrong as being able to use a 
different implementation strategy.  If a bit string has a fixed maximum 
size that can fit in an int, and is being used to indicate flags you can 
avoid having to create an indefinite length bit string.

BTW,  evil thought:  if one were to dynamically create an object 
identifier with a known prefix and whose last component was the integer 
value of the context flags, and added that to the end of the mechList, 
wouldn't that allow upgraded implementations to detect flag changes 
without breaking legacy apps?

>technically it is a violation of id-nits to do so in an
I meant to say 'no page breaks/headers in the middle of the code' :) 
It's a  peeve.

[MICS]

>return complete if a MIC is required and the most preferred mechanism
(a)  "If the mechanism selected by the negotiation does not support 
integrity protection, then no mechlistMIC token is used.
(b)  "Otherwise, if the accepted mechanism is the most preferred 
mechanism of both the initiator and the  acceptor, then the MIC token 
exchange, as described later in this section, is OPTIONAL."
(c) "If no mechlistMIC token was included, and the MIC token exchange is 
not required, GSS_Init_sec_context() indicates GSS_S_COMPLETE with no 
output token

1: Alice initiates, offering  two protocols, one w/MIC, one wo/MIC 
{MIC,NOMIC}. Alice prefers MIC
2: Mallet rewrites  to  {NOMIC}
3: Bob is indifferent between MIC and NOMIC, and activates NOMIC
    by (a) and (b), the acceptor will  not generate a MIC token
    by (a) and (c) the initiator will indicate success

I guess the best thing to do is for the initiator not to offer MICless 
mechanisms unless all of them are preferred.

>GSSAPI always starts with an initiator (funny that).
Never mind - I see that any data passed in to the first call to 
initSecContext is always ignored.

>    Simon> 8) SPNEGO is an anagram of SPONGE.
Things you notice when you're coding against the original specs :)

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Dec 2004 17:52:33 +0100 (MET)

> They're also not part of the MIC.   It might be better to reuse 

God help us -- NO!

GSS-API is about trying as hard as possible to establish a security
context, even if it doesn't fulfil all of the desires of both peers.

Something like a critical extension would be a showstopper for
the handshake with a legacy SPNEGO installed base, which is entirely
alien to the GSS-API philosophy.

> avoid having to create an indefinite length bit string.

In case that we have a requirement for DER-encoding in SPNEGO, then
indefinite length encoding is not permitted.

> mechanisms unless all of them are preferred.

The security consideration section should sufficiently address the
problem with MICless mechanisms participating the negotiation.

> initSecContext is always ignored.

I really wouldn't count on such a token to be ignored.  Expect mechanisms
to abort with an error if the input_token to gss_init_sec_context()
is not NULL or an empty buffer as described in the C-Bindings (rfc2744).

The only (non-ietf) mechanism that I know which does this is Microsoft's
NTLM SSP, and as this mechanism uses a 3-leg authentication scheme
(challenge-response authentication), it needs that dirty hack badly
for the HTTP-negotiate authentication.

But the actual NTLM-hack in HTTP-Negotiate must be a magnitude worse,
because either you have to go through an additional error page for
each and every request, or ignore replayed authentication tokens
on subsequent requests and only force new TCP-connections through
an error-page which emits a new challenge (I haven't read that document...).

-Martin

---

From: Simon Spero <[email-masked]>
Date: Thu, 30 Dec 2004 12:59:02 -0500

>indefinite length encoding is not permitted.
I should have said unconstrained length.  If you have a bit string whose 
length is constrained enough to fit entirely in a machine word, you can 
generate a simpler implementation; bignum vs int.

Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Dec 2004 12:44:20 -0600

> critical extensions, and those extensions are only labeled by tag.   

I think there are things we can do with the existing mechList and
mechListMIC to securely negotiate extensions, in which case lack of
support by one peer for the other's critical extensions should simply
lead to failure.

Of course, designing SPNEGO for extensibility now would be better, but
we're aiming for a modicum of introperability with some existing,
deployed implementations under some common circumstances.  This places
some constraints on what we can do in terms of re-designing SPNEGO.

> They're also not part of the MIC.   It might be better to reuse 

The MIC can be made to include whatever we want it to in a future
extensions :)

Even today it can include lots of things other than mechanism OIDs,
basically, any OIDs that the initiator wants to advertise.

> without breaking legacy apps?

Or an OID per-flag set, then include all those OIDs int he mechList.

We've had this thought before.

[...]
> mechanisms unless all of them are preferred.

Yes, and Larry's I-D says so, doesn't it?  It's been known since the
days of the original SPNEGO that negotiation of mechanisms that do not
provide for integrity protection means that the negotiation can't be
protected.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 30 Dec 2004 12:46:34 -0600

> problem too and Nico does have drafts in that space.

Also, even if a given mechanism is supposed to provide for integrity
protection it's entirely possible that under some circumstances it might
not be able to and yet still be able to establish a security context,
but that would lead to failure where a mechListMIC is needed, or, if one
wasn't, to subsequent failure of the application.

Nico
--