code review request: 7077646: gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY

[Valerie (Yu-Ching) Peng]

The changes look good to me.
Thanks,
Valerie
On 09/22/11 08:05, Weijun Wang wrote:
> Webrev at
>
>   http://cr.openjdk.java.net/~weijun/7077646/webrev.00/
>
> According to RFC 4121 [1]:
>
>   2.  Key Derivation for Per-Message Tokens
>
>   ...
>
>    During the context initiation and acceptance sequence, the acceptor
>    MAY assert a subkey in the AP-REP message.  If the acceptor asserts a
>    subkey, the base key is the acceptor-asserted subkey and subsequent
>    per-message tokens MUST be flagged with "AcceptorSubkey", as
>    described in section 4.2.2.  Otherwise, if the initiator asserts a
>    subkey in the AP-REQ message, the base key is this subkey;  if the
>    initiator does not assert a subkey, the base key is the session key
>    in the service ticket.
>
> Java has not checked where the key comes from and always sets the 
> AcceptorSubkey on. This has worked well with the MIT impl because it 
> seems the MIT impl only checks the flag if it should be on but doesn't 
> when it should be off. However, Heimdal is more strict and check in 
> both cases and an interop error happens between Java and Heimdal.
>
> In the customer's case, the Apple iChat program uses Heimdal's krb5 
> impl and cannot communicate well with the Openfire Java jabber server.
>
> I would like >= 2 reviewers so it can be backported to a 7u release. 
> I'm still working on a 6u solution at the moment.
>
> Thanks
> Max
>
> [1]
>
> -------- Original Message --------
> *Change Request ID*: 7077646
>
> *Synopsis*: gssapi wrap for CFX per-message tokens always set 
> FLAG_ACCEPTOR_SUBKEY
>
>   Product: java
>   Category: jgss
>   Subcategory: krb5plugin
>
> === *Description* 
> ============================================================
> FULL PRODUCT VERSION :
>
>
> A DESCRIPTION OF THE PROBLEM :
> gssapi wrap for CFX per-message tokens always set FLAG_ACCEPTOR_SUBKEY 
> even though the acceptor doesn't send a sub key.
>
>
>
> STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
> attach debugger to client and see that the the acceptor doesn't send a 
> subkey in the authenticator, see what it sent FLAG_ACCEPTOR_SUBKEY in 
> all per-message tokens.
>
>
>
> EXPECTED VERSUS ACTUAL BEHAVIOR :
> EXPECTED -
> send subkey or don't set flag.
>
> REPRODUCIBILITY :
> This bug can be reproduced always.
>