[
https://issues.apache.org/jira/browse/WSS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-299:
------------------------------------
Affects Version/s: 1.5.11
1.6.1
Fix Version/s: 1.6.2
1.5.12
> UsernameToken Salt Mac/Encryption Flag on Wrong End of Array
> ------------------------------------------------------------
>
> Key: WSS-299
> URL: https://issues.apache.org/jira/browse/WSS-299
> Project: WSS4J
> Issue Type: Bug
> Affects Versions: 1.5.11, 1.6.1
> Reporter: Patrick Ryan
> Assignee: Colm O hEigeartaigh
> Fix For: 1.5.12, 1.6.2
>
>
> In UsernameToken Profile key derivation, the flag that indicates the use for
> the salt is being placed on the wrong end. It should be at index 0 but is
> being placed at index 15. See
> org.apache.ws.security.message.token.UsernameToken.generateSalt(boolean).
> The UsernameToken Profile 1.1 spec says
> > "The high order 8 bits of the Salt will have the value of 01 if the key
> > is to be used in a MAC and 02 if the key is to be used for encryption.
> > The remaining 120 low order bits of the Salt should be a random value."
> Java is big endian, which means the high order values come first (i.e. high
> byte is at index 0 of a byte array). From
> http://en.wikipedia.org/wiki/Endianness
> > "The usual contrast is whether the most-significant or least-significant
> > byte is ordered first - i.e. at the lowest byte address - within the
> > larger data item. A big-endian machine stores the most-significant byte
> > first (at the lowest address), and a little-endian machine stores the
> > least-significant byte first. In these standard forms, the bytes remain
> > ordered by significance."
> Looking at other UsernameToken Profile implementations turned up this
> example:
> http://blogs.oracle.com/SureshMandalapu/entry/passwordderivedkeys_support_in_metro
> which clearly shows the salt flag is at index 0 of the byte array:
> > Absds/FHfgh/swderfa== decodes to 01bb1db3f1477e087fb3075eadf6
> (when printing the byte array in hex starting at index 0).
> And, in my discussion with Colm to confirm this issue, I asked what should be
> done about salt validation. Here is what he said:
> > Hi Patrick,
> >
> > > Doesn't that mean index 0 of an array should hold the most significant
> > > value?
> >
> > Yes, I think you're right. Could you submit a JIRA and patch?
> >
> > > * check both ends and if only one end is either 1 or 2,
> > > then use that to validate the usage of the derived key
> > > * if both ends contain either a 1 or 2 then skip validation on
> > > the usage of the derived key
> > > * if neither end has a 1 or a 2, then fail validation
> >
> > That sounds reasonable to me. I think it could be extended so that we
> > validate that the correct flag has been set for signature
> > verification, or for decryption, when using a derived key - I don't
> > think the current code does this.
> >
> > Thanks,
> >
> > Colm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
