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

[Weijun Wang]

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