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

[Vincent Ryan]

Your fix looks good Max.

On 1 May 2013, at 11:31, Weijun Wang wrote:

> 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