Code review request: 8012082: SASL auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt

[Weijun Wang]

Ping again.

On 4/19/13 8:56 AM, Weijun Wang wrote:
> Resubmitted at http://cr.openjdk.java.net/~weijun/8012082/webrev.01/.
>
> Now, when unwrap is called, it does *not* check if the message received
> matches the QoP. So when auth-conf is negotiated, one side can send an
> unencrypted token and the other side will accept it. It just will not
> forget its own QoP.
>
> This is the same behavior as Cyrus SASL and GNU SASL.
>
> Thanks
> Max
>
> On 4/18/13 12:19 PM, Weijun Wang wrote:
>> Webrev withdrawn. I'm studying the behavior of several third-party SASL
>> impls to see how they deal with this.
>>
>> Stay tuned.
>>
>> -Max
>>
>> On 4/17/13 6:39 PM, Weijun Wang wrote:
>>> Hi Valerie or Vinnie
>>>
>>> Please take a review on this fix
>>>
>>>     http://cr.openjdk.java.net/~weijun/8012082/webrev.00/
>>>
>>> Bug is
>>>
>>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012082
>>>
>>> The problem is that a single MessageProp is used in all wrap and unwrap
>>> calls and the output value is not checked.
>>>
>>> After the output check, it looks like it's OK to share the MessageProp
>>> object (because once it's changed, an exception is thrown), but I create
>>> one for each wrap/unwrap to be safe and clean, and I don't know if there
>>> are applications trying to "recover" from an exception.
>>>
>>> This is not a security issue, it's after the peer establishing the
>>> security context, therefore already authenticated.
>>>
>>> Thanks
>>> Max