You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by br...@www.sweetxml.org on 2004/10/27 18:34:04 UTC
Re: signing with DerivedKey based on UsernameToken - data for alg. test
Hey Werner
I havn't had time to do any testing, but a had a guy doing a .NET request without encryption son that we have data to check the algorithm:
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
<wsse:Username>DOM\myname</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypass</wsse:Password>
<wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
<wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
</wsse:UsernameToken>
<SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
I've attached the complete request.
/Brian
On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
> Brian,
>
> do you use the WSE TP or WSE SP1? hervewy's blog says that
> WSE TP (technical preview) may have (or has) a bug that it
> uses the WS-Security label as ASCII, not as UTF-8. Our code
> uses UTF-8. IMHO it should not make a difference because
> the label uses ASCII codes only (not sure though...need to
> check it out somehow).
>
> In addition, hervewy's blog says that they use only 16 bytes
> of the hash as key material. Our P_Hash now produces 128 Bytes
> of key material (according to RFC for TLS). IMO this needs
> to be adjusted. I'll try to get more info about the algo
> an how it is applied by WSE.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
> > Gesendet: Mittwoch, 27. Oktober 2004 10:00
> > An: fx-dev@ws.apache.org
> > Betreff: RE: signing with DerivedKey based on UsernameToken
> >
> >
> > Werner,
> >
> > Thanks for keeping going :-) Here are a small catch up from
> > yesterday, but unfortunately still no break though, it's the
> > same exception as before:
> >
> > 1) Namespace af Addressing. You are right that there was a
> > mismatch, thanks for pointing it out. I've looked into it and
> > the reason seems to be, that the addressing implemtation has
> > updated the namespace recently, and I have not had the time
> > to follow the spec. I had pasted that part of min client
> > deployer from another interop test, where it worked with WSE,
> > and looking back into the succesfull reqeust from a .NET WSE
> > client, I've confirmed that it's the
> >
> > xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
> >
> > that WSE uses.
> >
> > 2) Label. Sorry for the stupid question, I finally got the
> > curage to look into the code, and was surprised with how easy
> > it was to read/understand - well done!
> >
> > 3) algorithm. From my level of understanding it looks
> > allright, the only resource that might have som new info is this:
> > http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
> k.webservices.enhancements/post105194.asp
> That describes the changes to the implementation in WSE from the TP to SP1.
> Today I'll try to get on of the .NET guys produce a request thats not encrypted, so we can have a direct check of algoritm, and it may turn out that it's some other thing thats bugging me.
>
>
> Brgds
> Brian
>
>
>
>
>
>
> Brian,
>
> the first error (Element not found) is because the signatureParts
> specify a wrong element name or namespace. I checked with the
> XML request you sent sometime ago and found that you specified
> a wrong namespace in signatureParts. The namespace should
> be
> http://schemas.xmlsoap.org/ws/2004/08/addressing
>
> and not
>
> http://schemas.xmlsoap.org/ws/2004/03/addressing
>
> For the second error I'll try to get some more info about
> the algorithms etc.
>
> Regards,
> Werner
RE: signing with DerivedKey based on UsernameToken - data for alg.
test
Posted by Dimuthu Leelarathne <mu...@opensource.lk>.
Hi Brian,
If you want to sign using the password assoiciated with the Username token
what you have to use is HMAC-SHA1 signature. Which is basically a hash
function. The standard is if you want to sign a SOAP message using a
symmetric key (eg. Password or any shared secret) then you have to use
HMAC-SHA1 signature. As I undersatand this is what I think you want to do.
The implementation is available at
org.apache.ws.security.conversation.ConversationManager.java
The method signature is::
public Document build(Document doc, Reference ref, byte[] sk, Vector parts)
throws WSSecurityException {
If you want to sign using derived keys then you have to start secure
conversation between two parties. Then it is a different story.
> What I've found about the signature with derived key: there are about
> three
> different descriptions about how to do it. Some say WSE uses 16 bytes as
> key
> material,others say 24 bytes, one say the key includes the creation time,
> some indicate that it is without the creation time.
You can read all about derived keys in WS-Secure Conversation
specification. Derivedkeys can have any no of key material bytes - the
point is the communication parties should agree first, according to
WS-Policy specification.
Currently available implemenatation at WSS4J doesn't support code to start
WS-Secure Converation using Username tokens. However we have made
provisions enable it.
Regards,
Dimuthu
--
Lanka Software Foundation http://www.opensource.lk
> Hey Werner,
>
> It sure isn't easy but hopefully were soon done and let's hope we will end
> op with a clear understanding that others can benefit from as well -
> should
> it be that my problem actually was something else :-)
>
> I've attached the text-file i got from the .NET developer, that he made
> with
> his MS trace tool. I'm sort of surprised that whitespaces can change the
> signature, i thought that canonical XML took care of that, sorry to find
> my
> knowledge so incomplete, but luckily it isn't me doing the coding here!
>
>
> Brgds Brian
>
>
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> Sent: Saturday, October 30, 2004 2:55 PM
> To: brian@www.sweetxml.org
> Cc: fx-dev@ws.apache.org
> Subject: Re: signing with DerivedKey based on UsernameToken - data for
> alg.
> test
>
>
> Brian,
>
> What I've found about the signature with derived key: there are about
> three
> different descriptions about how to do it. Some say WSE uses 16 bytes as
> key
> material,others say 24 bytes, one say the key includes the creation time,
> some indicate that it is without the creation time. Using the test program
> I
> can cycle through various options to check the signature.
>
> I've set up a test programm and checked several things. Unfortunatly I
> can't
> do all checks because the XML request was "pretty printed", i.e. contains
> blanks and tabs to format the output. This pretty printing prevents a
> signature check. Can you try to get such a request as a non-pretty printed
> version?
>
> Regards,
> Werner
>
> brian@www.sweetxml.org wrote:
>> Hey Werner
>>
>> I havn't had time to do any testing, but a had a guy doing a .NET
>> request without encryption son that we have data to check the algorithm:
> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>> <wsse:Username>DOM\myname</wsse:Username>
>> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>> </wsse:UsernameToken>
>>
>> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>>
>>
>> I've attached the complete request.
>>
>>
>> /Brian
>>
>>
>>
>> On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
>>
>>>Brian,
>>>
>>>do you use the WSE TP or WSE SP1? hervewy's blog says that WSE TP
>>>(technical preview) may have (or has) a bug that it uses the
>>>WS-Security label as ASCII, not as UTF-8. Our code uses UTF-8. IMHO it
>>>should not make a difference because the label uses ASCII codes only
>>>(not sure though...need to check it out somehow).
>>>
>>>In addition, hervewy's blog says that they use only 16 bytes of the
>>>hash as key material. Our P_Hash now produces 128 Bytes of key
>>>material (according to RFC for TLS). IMO this needs to be adjusted.
>>>I'll try to get more info about the algo an how it is applied by WSE.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
>>>>Gesendet: Mittwoch, 27. Oktober 2004 10:00
>>>>An: fx-dev@ws.apache.org
>>>>Betreff: RE: signing with DerivedKey based on UsernameToken
>>>>
>>>>
>>>>Werner,
>>>>
>>>>Thanks for keeping going :-) Here are a small catch up from
>>>>yesterday, but unfortunately still no break though, it's the
>>>>same exception as before:
>>>>
>>>>1) Namespace af Addressing. You are right that there was a
>>>>mismatch, thanks for pointing it out. I've looked into it and
>>>>the reason seems to be, that the addressing implemtation has
>>>>updated the namespace recently, and I have not had the time
>>>>to follow the spec. I had pasted that part of min client
>>>>deployer from another interop test, where it worked with WSE,
>>>>and looking back into the succesfull reqeust from a .NET WSE
>>>>client, I've confirmed that it's the
>>>>
>>>>xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
>>>>
>>>>that WSE uses.
>>>>
>>>>2) Label. Sorry for the stupid question, I finally got the
>>>>curage to look into the code, and was surprised with how easy
>>>>it was to read/understand - well done!
>>>>
>>>>3) algorithm. From my level of understanding it looks
>>>>allright, the only resource that might have som new info is this:
>>>>http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
>>>
>>>k.webservices.enhancements/post105194.asp
>>>That describes the changes to the implementation in WSE from the TP to
>>>SP1. Today I'll try to get on of the .NET guys produce a request thats
>>>not encrypted, so we can have a direct check of algoritm, and it may
>>>turn out that it's some other thing thats bugging me.
>>>
>>>
>>>Brgds
>>>Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>>Brian,
>>>
>>>the first error (Element not found) is because the signatureParts
>>>specify a wrong element name or namespace. I checked with the XML
>>>request you sent sometime ago and found that you specified a wrong
>>>namespace in signatureParts. The namespace should be
>>>http://schemas.xmlsoap.org/ws/2004/08/addressing
>>>
>>>and not
>>>
>>>http://schemas.xmlsoap.org/ws/2004/03/addressing
>>>
>>>For the second error I'll try to get some more info about
>>>the algorithms etc.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>----------------------------------------------------------------------
>>>--
>>>
>>><?xml version="1.0" encoding="utf-8"?>
>>><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
> ty-secext-1.0.xsd"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd">
>>> <soap:Header>
>>> <wsa:Action
> wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservic
> e/service/public/2/GetDocumentByUrl</wsa:Action>
>>> <wsa:MessageID
> wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d
> 3-486818e60a43</wsa:MessageID>
>>> <wsa:ReplyTo
> wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>>>
> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
> </wsa:Address>
>>> </wsa:ReplyTo>
>>> <wsa:To
> wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservic
> e/service/public/2/documentmanager.asmx</wsa:To>
>>> <wsse:Security soap:mustUnderstand="1">
>>> <wsu:Timestamp
> wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>>>
> <wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires>
>>> </wsu:Timestamp>
>>> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>>> <wsse:Username>DOM\myname</wsse:Username>
>>> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>>>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>>>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>>> </wsse:UsernameToken>
>>> <Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#">
>>> <SignedInfo>
>>> <CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> <SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
>>> <Reference
> URI="#Id-8b02b27b-c25a-459a-a4df-a844b480147b">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue>
>>> </Reference>
>>> <Reference
> URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8">
>>> <Transforms>
>>> <Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>> </Transforms>
>>> <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>>
> <DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue>
>>> </Reference>
>>> </SignedInfo>
>>>
> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>>> <KeyInfo>
>>> <wsse:SecurityTokenReference>
>>> <wsse:Reference
> URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
> token-profile-1.0#UsernameToken"/>
>>> </wsse:SecurityTokenReference>
>>> </KeyInfo>
>>> </Signature>
>>> </wsse:Security>
>>> </soap:Header>
>>> <soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8">
>>> <DocumentUrl
> xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio
> .dk/accul/ultest.xsd</DocumentUrl>
>>> </soap:Body>
>>></soap:Envelope>
>>>
>
Re: signing with DerivedKey based on UsernameToken - data for alg.
test
Posted by Werner Dittmann <We...@t-online.de>.
Brian,
thanks for the soaplog. Now we have _SUCCESS_ !!
I was able to perform the Signature check with this request.
The following settings for the generation of the derived
UsernameToken key:
- The label value is "WS-Security", decode this string into bytes
with UTF-8 decoding
- get the _binary_ nonce value, i.e. decode from Base64 representation
- get the created element and decode it into bytes, using UTF-8
Concatenate the resulting byte array in the following order:
label + nonce + created
Now call P_Hash according to RFC 2246, using SHA-1 as hash algorithm
for the hashed message authentication code (HMACSHA1). Use the UTF-8
decoded password as key for the HMAC.
The first 16 bytes of the result of P_Hash are the key the signature.
BTW, XML c14n usually does not remove content from XML documents, it
may collapse/remove leading blanks, but IMHO c14n does not remove text
nodes completely, e.g. it leaves CR/NL. Thus running a pretty printer
definitly modifies an XML document (when you parse it again), thus a
signature check will fail.
I'll do some code cleanup and checkin the fixed code later this day.
Brian Nielsen wrote:
> Hey Werner,
>
> It sure isn't easy but hopefully were soon done and let's hope we will end
> op with a clear understanding that others can benefit from as well - should
> it be that my problem actually was something else :-)
>
> I've attached the text-file i got from the .NET developer, that he made with
> his MS trace tool. I'm sort of surprised that whitespaces can change the
> signature, i thought that canonical XML took care of that, sorry to find my
> knowledge so incomplete, but luckily it isn't me doing the coding here!
>
>
> Brgds Brian
>
>
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> Sent: Saturday, October 30, 2004 2:55 PM
> To: brian@www.sweetxml.org
> Cc: fx-dev@ws.apache.org
> Subject: Re: signing with DerivedKey based on UsernameToken - data for alg.
> test
>
>
> Brian,
>
> What I've found about the signature with derived key: there are about three
> different descriptions about how to do it. Some say WSE uses 16 bytes as key
> material,others say 24 bytes, one say the key includes the creation time,
> some indicate that it is without the creation time. Using the test program I
> can cycle through various options to check the signature.
>
> I've set up a test programm and checked several things. Unfortunatly I can't
> do all checks because the XML request was "pretty printed", i.e. contains
> blanks and tabs to format the output. This pretty printing prevents a
> signature check. Can you try to get such a request as a non-pretty printed
> version?
>
> Regards,
> Werner
>
> brian@www.sweetxml.org wrote:
>
>>Hey Werner
>>
>>I havn't had time to do any testing, but a had a guy doing a .NET
>>request without encryption son that we have data to check the algorithm:
>
> <wsse:UsernameToken
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>
>> <wsse:Username>DOM\myname</wsse:Username>
>> <wsse:Password
>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>
>></wsse:UsernameToken>
>>
>><SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>>
>>
>>I've attached the complete request.
>>
>>
>>/Brian
>>
>>
>>
>>On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
>>
>>
>>>Brian,
>>>
>>>do you use the WSE TP or WSE SP1? hervewy's blog says that WSE TP
>>>(technical preview) may have (or has) a bug that it uses the
>>>WS-Security label as ASCII, not as UTF-8. Our code uses UTF-8. IMHO it
>>>should not make a difference because the label uses ASCII codes only
>>>(not sure though...need to check it out somehow).
>>>
>>>In addition, hervewy's blog says that they use only 16 bytes of the
>>>hash as key material. Our P_Hash now produces 128 Bytes of key
>>>material (according to RFC for TLS). IMO this needs to be adjusted.
>>>I'll try to get more info about the algo an how it is applied by WSE.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
>>>>Gesendet: Mittwoch, 27. Oktober 2004 10:00
>>>>An: fx-dev@ws.apache.org
>>>>Betreff: RE: signing with DerivedKey based on UsernameToken
>>>>
>>>>
>>>>Werner,
>>>>
>>>>Thanks for keeping going :-) Here are a small catch up from
>>>>yesterday, but unfortunately still no break though, it's the
>>>>same exception as before:
>>>>
>>>>1) Namespace af Addressing. You are right that there was a
>>>>mismatch, thanks for pointing it out. I've looked into it and
>>>>the reason seems to be, that the addressing implemtation has
>>>>updated the namespace recently, and I have not had the time
>>>>to follow the spec. I had pasted that part of min client
>>>>deployer from another interop test, where it worked with WSE,
>>>>and looking back into the succesfull reqeust from a .NET WSE
>>>>client, I've confirmed that it's the
>>>>
>>>>xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
>>>>
>>>>that WSE uses.
>>>>
>>>>2) Label. Sorry for the stupid question, I finally got the
>>>>curage to look into the code, and was surprised with how easy
>>>>it was to read/understand - well done!
>>>>
>>>>3) algorithm. From my level of understanding it looks
>>>>allright, the only resource that might have som new info is this:
>>>>http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
>>>
>>>k.webservices.enhancements/post105194.asp
>>>That describes the changes to the implementation in WSE from the TP to
>>>SP1. Today I'll try to get on of the .NET guys produce a request thats
>>>not encrypted, so we can have a direct check of algoritm, and it may
>>>turn out that it's some other thing thats bugging me.
>>>
>>>
>>>Brgds
>>>Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>>Brian,
>>>
>>>the first error (Element not found) is because the signatureParts
>>>specify a wrong element name or namespace. I checked with the XML
>>>request you sent sometime ago and found that you specified a wrong
>>>namespace in signatureParts. The namespace should be
>>>http://schemas.xmlsoap.org/ws/2004/08/addressing
>>>
>>>and not
>>>
>>>http://schemas.xmlsoap.org/ws/2004/03/addressing
>>>
>>>For the second error I'll try to get some more info about
>>>the algorithms etc.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>----------------------------------------------------------------------
>>>--
>>>
>>><?xml version="1.0" encoding="utf-8"?>
>>><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
> ty-secext-1.0.xsd"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd">
>
>>> <soap:Header>
>>> <wsa:Action
>
> wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservic
> e/service/public/2/GetDocumentByUrl</wsa:Action>
>
>>> <wsa:MessageID
>
> wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d
> 3-486818e60a43</wsa:MessageID>
>
>>> <wsa:ReplyTo
>
> wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>
> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
> </wsa:Address>
>
>>> </wsa:ReplyTo>
>>> <wsa:To
>
> wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservic
> e/service/public/2/documentmanager.asmx</wsa:To>
>
>>> <wsse:Security soap:mustUnderstand="1">
>>> <wsu:Timestamp
>
> wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>
> <wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires>
>
>>> </wsu:Timestamp>
>>> <wsse:UsernameToken
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> y-utility-1.0.xsd"
> wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>
>>> <wsse:Username>DOM\myname</wsse:Username>
>>> <wsse:Password
>
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
> -profile-1.0#PasswordText">mypass</wsse:Password>
>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>
>>> </wsse:UsernameToken>
>>> <Signature
>
> xmlns="http://www.w3.org/2000/09/xmldsig#">
>
>>> <SignedInfo>
>>> <CanonicalizationMethod
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> <SignatureMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
>
>>> <Reference
>
> URI="#Id-8b02b27b-c25a-459a-a4df-a844b480147b">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue>
>
>>> </Reference>
>>> <Reference
>
> URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue>
>
>>> </Reference>
>>> <Reference
>
> URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue>
>
>>> </Reference>
>>> <Reference
>
> URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue>
>
>>> </Reference>
>>> <Reference
>
> URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue>
>
>>> </Reference>
>>> <Reference
>
> URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8">
>
>>> <Transforms>
>>> <Transform
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>
>>> </Transforms>
>>> <DigestMethod
>
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue>
>
>>> </Reference>
>>> </SignedInfo>
>>>
> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>
>>> <KeyInfo>
>>> <wsse:SecurityTokenReference>
>>> <wsse:Reference
>
> URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b"
> ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
> token-profile-1.0#UsernameToken"/>
>
>>> </wsse:SecurityTokenReference>
>>> </KeyInfo>
>>> </Signature>
>>> </wsse:Security>
>>> </soap:Header>
>>> <soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8">
>>> <DocumentUrl
>
> xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio
> .dk/accul/ultest.xsd</DocumentUrl>
>
>>> </soap:Body>
>>></soap:Envelope>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>-----SoapRequest at 10/27/2004 9:53:14 AM
>>><?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><soap:Header><wsa:Action wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservice/service/public/2/GetDocumentByUrl</wsa:Action><wsa:MessageID wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d3-486818e60a43</wsa:MessageID><wsa:ReplyTo wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba"><wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address></wsa:ReplyTo><wsa:To wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservice/servic
e/public/2/documentmanager.asmx</wsa:To><wsse:Security soap:mustUnderstand="1"><wsu:Timestamp wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143"><wsu:Created>2004-10-27T07:53:08Z</wsu:Created><wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b"><wsse:Username>DOM\myname</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypass</wsse:Password><wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce><wsu:Created>2004-10-27T07:53:08Z</wsu:Created></wsse:UsernameToken><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" /><Reference URI="#Id-8b02b27b-c25a-459a
-a4df-a844b480147b"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue></Reference><Reference URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue></Reference><Reference URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue></Reference><Reference URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://ww
w.w3.org/2000/09/xmldsig#sha1" /><DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue></Reference><Reference URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue></Reference><Reference URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue></Reference></SignedInfo><SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue><KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" /></wsse:SecurityTokenRe
ference></KeyInfo></Signature></wsse:Security></soap:Header><soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8"><DocumentUrl xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio.dk/accul/ultest.xsd</DocumentUrl></soap:Body></soap:Envelope>
>>>
RE: signing with DerivedKey based on UsernameToken - data for alg. test
Posted by Brian Nielsen <br...@sweetxml.org>.
Hey Werner,
It sure isn't easy but hopefully were soon done and let's hope we will end
op with a clear understanding that others can benefit from as well - should
it be that my problem actually was something else :-)
I've attached the text-file i got from the .NET developer, that he made with
his MS trace tool. I'm sort of surprised that whitespaces can change the
signature, i thought that canonical XML took care of that, sorry to find my
knowledge so incomplete, but luckily it isn't me doing the coding here!
Brgds Brian
-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: Saturday, October 30, 2004 2:55 PM
To: brian@www.sweetxml.org
Cc: fx-dev@ws.apache.org
Subject: Re: signing with DerivedKey based on UsernameToken - data for alg.
test
Brian,
What I've found about the signature with derived key: there are about three
different descriptions about how to do it. Some say WSE uses 16 bytes as key
material,others say 24 bytes, one say the key includes the creation time,
some indicate that it is without the creation time. Using the test program I
can cycle through various options to check the signature.
I've set up a test programm and checked several things. Unfortunatly I can't
do all checks because the XML request was "pretty printed", i.e. contains
blanks and tabs to format the output. This pretty printing prevents a
signature check. Can you try to get such a request as a non-pretty printed
version?
Regards,
Werner
brian@www.sweetxml.org wrote:
> Hey Werner
>
> I havn't had time to do any testing, but a had a guy doing a .NET
> request without encryption son that we have data to check the algorithm:
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
y-utility-1.0.xsd"
wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
> <wsse:Username>DOM\myname</wsse:Username>
> <wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
-profile-1.0#PasswordText">mypass</wsse:Password>
>
<wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>
<wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
> </wsse:UsernameToken>
>
> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>
>
> I've attached the complete request.
>
>
> /Brian
>
>
>
> On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
>
>>Brian,
>>
>>do you use the WSE TP or WSE SP1? hervewy's blog says that WSE TP
>>(technical preview) may have (or has) a bug that it uses the
>>WS-Security label as ASCII, not as UTF-8. Our code uses UTF-8. IMHO it
>>should not make a difference because the label uses ASCII codes only
>>(not sure though...need to check it out somehow).
>>
>>In addition, hervewy's blog says that they use only 16 bytes of the
>>hash as key material. Our P_Hash now produces 128 Bytes of key
>>material (according to RFC for TLS). IMO this needs to be adjusted.
>>I'll try to get more info about the algo an how it is applied by WSE.
>>
>>Regards,
>>Werner
>>
>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
>>>Gesendet: Mittwoch, 27. Oktober 2004 10:00
>>>An: fx-dev@ws.apache.org
>>>Betreff: RE: signing with DerivedKey based on UsernameToken
>>>
>>>
>>>Werner,
>>>
>>>Thanks for keeping going :-) Here are a small catch up from
>>>yesterday, but unfortunately still no break though, it's the
>>>same exception as before:
>>>
>>>1) Namespace af Addressing. You are right that there was a
>>>mismatch, thanks for pointing it out. I've looked into it and
>>>the reason seems to be, that the addressing implemtation has
>>>updated the namespace recently, and I have not had the time
>>>to follow the spec. I had pasted that part of min client
>>>deployer from another interop test, where it worked with WSE,
>>>and looking back into the succesfull reqeust from a .NET WSE
>>>client, I've confirmed that it's the
>>>
>>>xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
>>>
>>>that WSE uses.
>>>
>>>2) Label. Sorry for the stupid question, I finally got the
>>>curage to look into the code, and was surprised with how easy
>>>it was to read/understand - well done!
>>>
>>>3) algorithm. From my level of understanding it looks
>>>allright, the only resource that might have som new info is this:
>>>http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
>>
>>k.webservices.enhancements/post105194.asp
>>That describes the changes to the implementation in WSE from the TP to
>>SP1. Today I'll try to get on of the .NET guys produce a request thats
>>not encrypted, so we can have a direct check of algoritm, and it may
>>turn out that it's some other thing thats bugging me.
>>
>>
>>Brgds
>>Brian
>>
>>
>>
>>
>>
>>
>>Brian,
>>
>>the first error (Element not found) is because the signatureParts
>>specify a wrong element name or namespace. I checked with the XML
>>request you sent sometime ago and found that you specified a wrong
>>namespace in signatureParts. The namespace should be
>>http://schemas.xmlsoap.org/ws/2004/08/addressing
>>
>>and not
>>
>>http://schemas.xmlsoap.org/ws/2004/03/addressing
>>
>>For the second error I'll try to get some more info about
>>the algorithms etc.
>>
>>Regards,
>>Werner
>>
>>
>>----------------------------------------------------------------------
>>--
>>
>><?xml version="1.0" encoding="utf-8"?>
>><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
ty-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
y-utility-1.0.xsd">
>> <soap:Header>
>> <wsa:Action
wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservic
e/service/public/2/GetDocumentByUrl</wsa:Action>
>> <wsa:MessageID
wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d
3-486818e60a43</wsa:MessageID>
>> <wsa:ReplyTo
wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
</wsa:Address>
>> </wsa:ReplyTo>
>> <wsa:To
wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservic
e/service/public/2/documentmanager.asmx</wsa:To>
>> <wsse:Security soap:mustUnderstand="1">
>> <wsu:Timestamp
wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>>
<wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>>
<wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires>
>> </wsu:Timestamp>
>> <wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
y-utility-1.0.xsd"
wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>> <wsse:Username>DOM\myname</wsse:Username>
>> <wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token
-profile-1.0#PasswordText">mypass</wsse:Password>
>>
<wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>>
<wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>> </wsse:UsernameToken>
>> <Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <SignedInfo>
>> <CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
>> <Reference
URI="#Id-8b02b27b-c25a-459a-a4df-a844b480147b">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue>
>> </Reference>
>> <Reference
URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue>
>> </Reference>
>> <Reference
URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue>
>> </Reference>
>> <Reference
URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue>
>> </Reference>
>> <Reference
URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue>
>> </Reference>
>> <Reference
URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8">
>> <Transforms>
>> <Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>
<DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue>
>> </Reference>
>> </SignedInfo>
>>
<SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>> <KeyInfo>
>> <wsse:SecurityTokenReference>
>> <wsse:Reference
URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
token-profile-1.0#UsernameToken"/>
>> </wsse:SecurityTokenReference>
>> </KeyInfo>
>> </Signature>
>> </wsse:Security>
>> </soap:Header>
>> <soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8">
>> <DocumentUrl
xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio
.dk/accul/ultest.xsd</DocumentUrl>
>> </soap:Body>
>></soap:Envelope>
>>
Re: signing with DerivedKey based on UsernameToken - data for alg.
test
Posted by Werner Dittmann <We...@t-online.de>.
Brian,
What I've found about the signature with derived key: there are about
three different descriptions about how to do it. Some say WSE uses
16 bytes as key material,others say 24 bytes, one say the key includes
the creation time, some indicate that it is without the creation time.
Using the test program I can cycle through various options to check
the signature.
I've set up a test programm and checked several things. Unfortunatly
I can't do all checks because the XML request was "pretty printed", i.e.
contains blanks and tabs to format the output. This pretty printing
prevents a signature check. Can you try to get such a request
as a non-pretty printed version?
Regards,
Werner
brian@www.sweetxml.org wrote:
> Hey Werner
>
> I havn't had time to do any testing, but a had a guy doing a .NET request without encryption son that we have data to check the algorithm:
> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
> <wsse:Username>DOM\myname</wsse:Username>
> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypass</wsse:Password>
> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
> </wsse:UsernameToken>
>
> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>
>
> I've attached the complete request.
>
>
> /Brian
>
>
>
> On Wed, Oct 27, 2004 at 09:28:35AM +0200, Dittmann Werner wrote:
>
>>Brian,
>>
>>do you use the WSE TP or WSE SP1? hervewy's blog says that
>>WSE TP (technical preview) may have (or has) a bug that it
>>uses the WS-Security label as ASCII, not as UTF-8. Our code
>>uses UTF-8. IMHO it should not make a difference because
>>the label uses ASCII codes only (not sure though...need to
>>check it out somehow).
>>
>>In addition, hervewy's blog says that they use only 16 bytes
>>of the hash as key material. Our P_Hash now produces 128 Bytes
>>of key material (according to RFC for TLS). IMO this needs
>>to be adjusted. I'll try to get more info about the algo
>>an how it is applied by WSE.
>>
>>Regards,
>>Werner
>>
>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: brian@sweetxml.org [mailto:brian@sweetxml.org]
>>>Gesendet: Mittwoch, 27. Oktober 2004 10:00
>>>An: fx-dev@ws.apache.org
>>>Betreff: RE: signing with DerivedKey based on UsernameToken
>>>
>>>
>>>Werner,
>>>
>>>Thanks for keeping going :-) Here are a small catch up from
>>>yesterday, but unfortunately still no break though, it's the
>>>same exception as before:
>>>
>>>1) Namespace af Addressing. You are right that there was a
>>>mismatch, thanks for pointing it out. I've looked into it and
>>>the reason seems to be, that the addressing implemtation has
>>>updated the namespace recently, and I have not had the time
>>>to follow the spec. I had pasted that part of min client
>>>deployer from another interop test, where it worked with WSE,
>>>and looking back into the succesfull reqeust from a .NET WSE
>>>client, I've confirmed that it's the
>>>
>>>xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
>>>
>>>that WSE uses.
>>>
>>>2) Label. Sorry for the stupid question, I finally got the
>>>curage to look into the code, and was surprised with how easy
>>>it was to read/understand - well done!
>>>
>>>3) algorithm. From my level of understanding it looks
>>>allright, the only resource that might have som new info is this:
>>>http://www.eggheadcafe.com/ng/microsoft.public.dotnet.framewor
>>
>>k.webservices.enhancements/post105194.asp
>>That describes the changes to the implementation in WSE from the TP to SP1.
>>Today I'll try to get on of the .NET guys produce a request thats not encrypted, so we can have a direct check of algoritm, and it may turn out that it's some other thing thats bugging me.
>>
>>
>>Brgds
>>Brian
>>
>>
>>
>>
>>
>>
>>Brian,
>>
>>the first error (Element not found) is because the signatureParts
>>specify a wrong element name or namespace. I checked with the
>>XML request you sent sometime ago and found that you specified
>>a wrong namespace in signatureParts. The namespace should
>>be
>>http://schemas.xmlsoap.org/ws/2004/08/addressing
>>
>>and not
>>
>>http://schemas.xmlsoap.org/ws/2004/03/addressing
>>
>>For the second error I'll try to get some more info about
>>the algorithms etc.
>>
>>Regards,
>>Werner
>>
>>
>>------------------------------------------------------------------------
>>
>><?xml version="1.0" encoding="utf-8"?>
>><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
>> <soap:Header>
>> <wsa:Action wsu:Id="Id-8b02b27b-c25a-459a-a4df-a844b480147b">http://isb.oio.dk/oioservice/service/public/2/GetDocumentByUrl</wsa:Action>
>> <wsa:MessageID wsu:Id="Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">uuid:e64aee56-d6f8-4960-93d3-486818e60a43</wsa:MessageID>
>> <wsa:ReplyTo wsu:Id="Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
>> </wsa:ReplyTo>
>> <wsa:To wsu:Id="Id-7a148a95-bf4f-418e-b346-34f1850a747a">http://isb.oio.dk/oioservice/service/public/2/documentmanager.asmx</wsa:To>
>> <wsse:Security soap:mustUnderstand="1">
>> <wsu:Timestamp wsu:Id="Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>> <wsu:Expires>2004-10-27T07:58:08Z</wsu:Expires>
>> </wsu:Timestamp>
>> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b">
>> <wsse:Username>DOM\myname</wsse:Username>
>> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">mypass</wsse:Password>
>> <wsse:Nonce>EESnwJLAxbN+1ewmFjS7vw==</wsse:Nonce>
>> <wsu:Created>2004-10-27T07:53:08Z</wsu:Created>
>> </wsse:UsernameToken>
>> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
>> <SignedInfo>
>> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
>> <Reference URI="#Id-8b02b27b-c25a-459a-a4df-a844b480147b">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>5f/DlekD21FRY8CPIbhVUI4WlUU=</DigestValue>
>> </Reference>
>> <Reference URI="#Id-d9abd0e7-b2f7-43a6-913c-af97dd3dd681">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>pmcAyJ0DsGlZg6YG0oEIL/hiegA=</DigestValue>
>> </Reference>
>> <Reference URI="#Id-a7a5ce82-b991-4d76-a6f9-ba51f3bde3ba">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>AWMEowRtbhkxnytKxHISG5rKJZU=</DigestValue>
>> </Reference>
>> <Reference URI="#Id-7a148a95-bf4f-418e-b346-34f1850a747a">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>kCnWkPvg6kHs9iqqPmsppQnZtjQ=</DigestValue>
>> </Reference>
>> <Reference URI="#Timestamp-83a4dbaa-34ff-4640-855c-0d0c97fc5143">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>sAVzaMAg0UTonyJeqidnDZf0hso=</DigestValue>
>> </Reference>
>> <Reference URI="#Id-f063763f-6e9d-4682-a024-0546c28581d8">
>> <Transforms>
>> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>> </Transforms>
>> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>> <DigestValue>BtjdaiUHt96rdwH0WyeYhYrvCMY=</DigestValue>
>> </Reference>
>> </SignedInfo>
>> <SignatureValue>T3uwLUIaZNWqTcvH0stfkt8CQ4g=</SignatureValue>
>> <KeyInfo>
>> <wsse:SecurityTokenReference>
>> <wsse:Reference URI="#SecurityToken-fc43cebf-ae98-4796-a099-026e4385c96b" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/>
>> </wsse:SecurityTokenReference>
>> </KeyInfo>
>> </Signature>
>> </wsse:Security>
>> </soap:Header>
>> <soap:Body wsu:Id="Id-f063763f-6e9d-4682-a024-0546c28581d8">
>> <DocumentUrl xmlns="http://isb.oio.dk/oioservice/service/DocumentManager/">http://rep.oio.dk/accul/ultest.xsd</DocumentUrl>
>> </soap:Body>
>></soap:Envelope>
>>