Re: gs2 and qop

[Simon Josefsson <jas@xxxxxxxxxxx>]

Sam Hartman <hartmans-ietf@xxxxxxx> writes:

>>>>>> "Simon" == Simon Josefsson <jas@xxxxxxxxxxx> writes:
>
>     >> Are you talking about gss-api level qop or sasl security
>     >> layers?
>
>     Simon> SASL security layers.
>
> I skip your answers to the rest of my questions because they assumed
> you meant GSS QOP.
>
> I'm failing to see the downgrade attack here though: if integ_avail is
> false, you don't negotiate security layers.
> Provided you enforce that what is the downgrade issue.

GS2 doesn't enforce that right now.  Instead, GS2 would fail the
authentication, because the integ_avail flag was not set.  I suppose
that GS2 could accept this situation and continue.  This would be
insecure: the authorization identity is not integrity protected.  I
wouldn't want to see wide use of a mechanism that has such an obvious
security problem.  However, the SASL framework permits this.

Is the consensus that GS2 should support GSS-API mechanisms that
doesn't offer integrity protection?

If so, the document should also say that channel bindings MUST NOT be
negotiated when integ_avail is false, because the channel bindings in
that situation would also not integrity protected.

> Some editorial comments on the draft:
>
> In your examples you do separate parts of packets input to gss_wrap
> with ,.  I'd suggest |.
>
> You never clearly define that the qop values you talk about correspond
> to the security layer stuff in section 9.

Thanks, the updated document should address this.

/Simon