Subject: SPNEGO

From: Denis Pinkas <[email-masked]>
Date: Fri, 19 Dec 1997 16:45:59 -0800

At the last IETF meeting the remaining issue about SPNEGO was the
processing of the mechList MIC. We advertised during the second CAT
session that a small group agreed on a text provided by Marc.

Since then I have had further exchanges with Mike Swift and hereafter
you will see what I hope to be acceptable to every one before I include
it in a revised version of SPNEGO.

Since Marc, Mike and Martin were involved in the discussion, could they
confirm that this text (slightly different from the text from Marc) is
acceptable to them ?

Here is the text that fits in section 4.2.2.

4.2.2. Processing of mechListMIC.

    If the mechanism selected by the negotiation does not support 
    integrity, then no mechListMIC is included, otherwise a 
    mechListMIC must be used and validated as indicated below.

    If the mechanism supports integrity and uses an even number of
    messages, then the target must compute a MIC as described above, 
    and send this in the final NegTokenTarg along with the final
    preferredToken. The initiator when receiving the last token must 
    require that the mechListMIC field be present and valid. In the 
    absence of a valid mechListMIC, the negotiation must fail as if 
    the last context establishment token was invalid.

    In the case that the chosen mechanism supports integrity and uses 
    an odd number of messages, the final mechanism token will be sent 
    from the initiator to the target. In this case, there is a 
    tradeoff between using the optimal number of messages, or using an 
    additional message from the target to the initiator in order to 
    give the initiator assurance that no modification of the 
    initiator's mechanism list occurred. The implementation can choose 
    which tradeoff to make. When generating the final NegTokenInit 
    message, the NegTokenInit may optionally include a mechListMIC 
    which is the result of a GetMIC of the MechTypes in the initial 
    NegTokenInit and return GSS_S_COMPLETE. The target must check the 
    presence of the MIC computed over the mechList sent in the initial 
    NegTokenInit. Three cases may then be considered:
         1) If the mechListMIC is present and correct the context is 
            established by the target. 
         2) If the mechList is present but corrupted, then the context 
            establishment must fail.
         3) If the mechListMIC is not included in the final 
            NegTokenInit, then GSS_S_CONTINUE_NEEDED must be returned 
            to the target. The MIC must then be included in the 
            NegTokenTarg as described above, and the NegTokenTarg must 
            be sent back to the initiator, which must verify that the 
            mechListMIC field is present and valid.
                 If the MIC was originally sent by the initiator, but 
                 thenafter deleted by an attacker, the target will 
                 send back a token according to the description above, 
                 but the initiator will be unable to process that 
                 returned token and the context establishment must 
                 then fail.

-- 

      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