You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Patrick Ryan (JIRA)" <ji...@apache.org> on 2011/07/05 01:12:21 UTC
[jira] [Created] (WSS-299) UsernameToken Salt Mac/Encryption Flag
on Wrong End of Array
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
Reporter: Patrick Ryan
Assignee: Colm O hEigeartaigh
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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Updated] (WSS-299) UsernameToken Salt Mac/Encryption Flag
on Wrong End of Array
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Closed] (WSS-299) UsernameToken Salt Mac/Encryption Flag on
Wrong End of Array
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-299.
-----------------------------------
> 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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Resolved] (WSS-299) UsernameToken Salt Mac/Encryption Flag
on Wrong End of Array
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-299.
-------------------------------------
Resolution: Fixed
> 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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org