Subject: RE: SPNEGO status

From: "Linn, John" <[email-masked]>
Date: Thu, 6 Nov 1997 14:33:38 -0500

Denis wrote the attached content to the list on 27 October, and the
SPNEGO thread then quiesced; I'd like to retrigger in the interests of
reaching closure.

Re (1), would we have consensus on text which is silent as to whether or
not OIDs are hierarchically related?

How can we proceed to convergence on (2)?

--jl

> ----------
> 
> Bill Sommerfeld wrote:
> 
> (...)
> 
> > > Since you did not comment on the two other points, should I
> understand
> > > that you accept my proposals which were:
> > 
> > Silence does not equal assent.
> > 
> > > 1) the possibility to negotiate mechanism-specific options during
> the
> > > negotiation should be maintained.
> > >
> > > Martin commented :
> > >
> > > " Absent comparable counterproposals to accomplish the QOP
> negotiation,
> > > I personally think it is acceptable."
> > 
> > Please be more specific about this.  In particular, I believe that
> the
> > wording about hierarchical mechanism OID's should be stricken from
> the
> > draft; similar functionality can be accomplished when necessary by
> > defining a family of mechanisms with related (or unrelated) OID's..
> 
> True. The OIDs may or may not be hierarchical.
> 
> > > 2) the mechListMic, when sent by the client, should not be added.
> > >
> > > Martin commented :
> > >
> > > " I don't have any personal preference on this issue."
> > 
> > No, because this may add an additional message of overhead on some
> > mechanisms, and I believe that a modest increase in complexity is
> > worth a savings in the number of messages required to complete the
> > negotiation.
> 
> This seems, now the last remaining issue. Could you provide an example
> where the added complexity is worthwhile ? 
> 
> Denis
> 
> -- 
> 
>       Denis Pinkas     Bull S.A.         E-mail :
> [email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 
>

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 15 Nov 1997 18:48:17 -0500

From: "Linn, John" <[email-masked]>
   Date: Thu, 6 Nov 1997 14:33:38 -0500

My apologies for not really commenting on this draft until recently; a
few other high-priority projects have been keeping me rather busy
recently. 

I would be very happy with the proposed compromise where the text is
silent as to whether or not OID's are hierarchically related.  This
would presumably include places where the text talks about "OID
extensions". 

Well, my two cents is that I think we should add mechListMIC to the
negTokenInit message.  This will eliminate a half-round trip in a number
of cases, and the amount of complexity it adds is very small.

						- Ted

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Nov 1997 10:22:59 -0800

I have posted to the IETF a revised version of spnego
(draft-ietf-cat-snego-07.txt) which should be available soon on the ftp
server. I have re-used the document updated by Marc as a basis. I have
made the following modifications:

1) Add on page 2 the following paragraph:

" This allows to negotiate different security mechanisms, different
options within a given security mechanism (such as different
cryptographic algorithms due to policy or legislative constraints) or
different options from several security mechanisms."

2) Change on page 2: "Each OID represents one GSS-API mechanism." into
"Change : Each OID represents one GSS-API mechanism or one variant of
it."

3) Change on page 3 :"Targets should respond to the initial security
token for the desired mechanism when it is present" into " When the
first mechanism is acceptable to the target,it should respond to the
initial security token for the desired mechanism of the initiator when
it is present.

4) Change the name of the "referredToken"from the NegTokenTarg into
"responseToken" in order to avoid confusion with the same name from the
NegTokenInit, since the responseToken is no more necessarily a response
to the preferred token.

5) Suppress on page 6, the mechListMIC from the NegTokenInit.

6) Delete : " Further tokens, when needed, contain only the
preferredToken which is a token specific to the selected mechanism.  If
the underlying mechanism uses an odd number of messages, so that the
final token is sent from the initiator to the target, then the final
token will also include a mechListMIC as described below."

> would presumably include places where the text talks about "OID

I have modified the text to address this concern.

I have requested several times an example on the real benefit of the
mechListMIC in the negTokenInit message. Given that no one has provided
such an example and despite the "two cents" from Ted  :-) I have not
incorporated this feature in the revised document.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 17 Nov 1997 13:51:44 -0500

> different options from several security mechanisms."

I object to the phrase "or legislative".  From the point of view of
protocol implementations, policy is policy, regardless of whether it
originates from the owner/user of the system, the developer, an
employer, political entities, etc., etc.,

> "Change : Each OID represents one GSS-API mechanism or one variant of

I object.  This would require changes to the base GSSAPI drafts.
Currently, my understanding is that each GSSAPI mechanism can be
selected by a single OID.  A family of related mechanisms will have a
family of OIDs, which will either be related or unrelated to each
other.

> initial security token for the desired mechanism of the initiator when

No objection.

> 5) Suppress on page 6, the mechListMIC from the NegTokenInit.

Objection; see below.

> incorporated this feature in the revised document.

I have, in fact, argued in favor of this feature in the past but due
to limitations on my time haven't had a chance to pull together a full
example.

here's a specific example:

Kerberos with synchronized clocks requires only a single message to
establish a shared key between two parties.  Strictly speaking, mutual
authentication is not done, but if all subsequent traffic is encrypted
using a key derived from the authenticator, this is not a problem in
practice because, since axiomatically only the authentic recipient can
know the long term key of the destination principal, and thus only the
recipient can learn the session key.

This means that one could construct a system which used spnego,
gssapi, and kerberos, and, *in the normal case* required only a single
message per transaction.. by requiring the response message, you add a
round trip wait to the initiator's workload.

					- Bill

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 17 Nov 1997 21:17:27 -0500

Date: Mon, 17 Nov 1997 10:22:59 -0800
   From: Denis Pinkas <[email-masked]>

I had thought the benefts were clear.  Consider the case of an
negotiation with a mechanism that only required (say) three messages to
complete:  Initiator->Acceptor, Acceptor->Initiator, Initiator->Acceptor.

If the mechListMIC were included in the negTokenInit message, then the
MIC can be included in the last Initiator->Acceptor message.  If it is
not, then you need an extra message from the Acceptor to the Initiator.

This is a real benefit.

						- Ted