Re: AD Review for draft-ietf-sasl-gssapi-xx.txt

[Simon Josefsson <jas@xxxxxxxxxxx>]

Alexey Melnikov <alexey.melnikov@xxxxxxxxx> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <alexey.melnikov@xxxxxxxxx> writes:
>>  
>>
>>>After the followup conversation with Sam he convinced me that this is
>>>the right thing.
>>>
>>>OLD text:
>>>  If the client will be requesting a security
>>>  layer, it MUST also supply to the GSS_Init_sec_context a
>>>  mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
>>>  integ_req_flag of TRUE.  If the client will be requesting a security
>>>  layer providing confidentiality protection, it MUST also supply to
>>>  the GSS_Init_sec_context a conf_req_flag of TRUE.
>>>
>>>NEW text:
>>>
>>> When calling the GSS_Init_sec_context the client MUST
>>> pass the integ_req_flag of TRUE. If the client will be requesting a
>>>security
>>> layer, it MUST also supply to the GSS_Init_sec_context a
>>> mutual_req_flag of TRUE, and a sequence_req_flag of TRUE.
>>> If the client will be requesting a security
>>> layer providing confidentiality protection, it MUST also supply to the
>>> GSS_Init_sec_context a conf_req_flag of TRUE.
>>>    
>>>
>>
>>The same text is found in the GS2 document as well.  I have made the
>>same change in it, but I also added:
>>
>>   The client MUST verify that the requested flags become enabled in
>>   the context.
>>  
>>
> As per discussion between Jeff and Sam I've already added the
> following text to -08.
>
> When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
> examines the context to ensure that it provides a level of protection
> permitted by the server's security policy.
> In particular, if the integ_avail flag is not set in the context,
> then no security layer can be offered or accepted. If the conf_avail
> flag is not set in the context, then no security layer with
> confidentiality can be offered or accepted.
>
> (the first sentence was already in the document).
>
> And similar text in the client side section.

That work slightly different in GS2 because the GSS_Wrap token, with
the qop information, is sent before GSS_Accept_sec_context returns
GSS_S_COMPLETE.

On the other hand, the client/server can verify the returned flags
after the context has been set up, and if it turns out it cannot offer
security layers, it abort the authentication.  This is still possible.

> Jeff/Sam came to conclusion that checking for integ_avail is not
> needed, unless a SASL security layer is negotiated.
> They didn't request any text regarding other flags.
>
> Sam, can you post a digest of why this is the case?

This seems wrong to me -- the "GSSAPI" authentication requires that
the QOP is integrity protected by GSS_Wrap.  If the GSS context can't
provide integrity for GSS_Wrap, there is a downgrade attack on the
QOPs.

For GS2, the situation is worse, since GSS_Wrap protects the channel
binding, and you really want integrity protection of the channel
binding data.

/Simon

>>I suggest that the same, or similar, text is added to GS1.
>>
>>Without that text, it seems as if the mechanism could simply ignore
>>them, and (for the C bindings) that the RET_FLAGS variable indicate
>>that they were never negotiated.  That seems to be a fatal problem to
>>me.  Or am I missing something?
>>  
>>