← Prev in month ← Prev in thread
Next in thread → Next in month →

Comments on oasis-0005-wss-username-token-profile-1[1].0.pdf

From
Blake Dournaee <>
Date
2003-12-11T19:18:21+00:00
ID
003501c3c01c$7fb520e0$4067010a@blake
Thread
Comments on oasis-0005-wss-username-token-profile-1[1].0.pdf
All,

 

Here are my comments on the latest revision of the UsernameToken Profile. All of the line numbers correspond
to oasis-0005-wss-username-token-profile-1[1].0.pdf

 

 
Line
     107: Should ‘must’ be MUST?

 
Line
     117: The term ‘providers’ is used to describe a web service
     provider, yet in line 119, they are called ‘producers.’ Should
     we use consistent terminology here?

 
Lines
     199 and 200: Why are double quotes used around the username and password?
     This makes it look like there is some sort of special syntax needed for a
     string literal when used in the token element content.

 
It
     would be nice to see an example of the intermediate values for the Password_Digest computation. I tried the values given
     in the example starting with line 211, but the computation didn’t come
     out as expected. Can we include an example that has intermediate values? I
     think this will aid in the interoperability to know exactly how the
     computation works out (this is similar to what was done in XMLEnc for the symmetric key wrap examples).

 

I’ve taken a stab here
to try and produce the nonce value shown in the example, but it didn’t
come out correctly. Can someone point to my mistake or can we add this sort of
example to the document?

 

Password_Digest
=> Base64 ( SHA-1 ( nonce + created + password ) )

Let s => nonce+created+password

s
=> WScqanjCEAC4mQoBE07sAQ==+ || 2003-07-16T01:24:32Z

s
=> C1 E6 08 DE 75 DD F0 B8 CC 35 59 2C 08 A1 55 F2 DD EB 80 78 77 47 || 

        32
30 30 33 2D 30 37 2D 31 36 54 30 31 3A 32 34 3A 33 32
5A

SHA1(s) => E3 71 E3 FE 26
45 99 E9 13 A7 31 C7 DC D1 ED D8 A1 3B 9F D5

Base 64(SHA1(s)) =>
43Hj/iZFmekTpzHH3NHt2KE7n9U=

      

 
The
     ‘password hash’ vs ‘password
     equivalent’ issue has already been beat to death, but at first read
     it is still confusing as to why the wsse:PasswordText and wsse:PasswordDigest
     elements can *both* contain a
     hash of a password. It seems like hashes of passwords should belong in the
     wsse:PasswordDigest
     element and unhashed passwords should belong in
     the wsse:PasswordText element, but in reality
     this is not the case. 

     

     If I have a legacy system that just uses MD5 hashes of passwords, I need
     to use wsse:PasswordText,
     and not wsse:PasswordDigest. This is confusing.
     Can I propose some explanatory text as follows: (or can someone beat me on
     the head and say I’m wrong about this?)

 

“The wsse:PasswordText element should
be used when hashed password equivalents that do not rely on a nonce or
creation time are used, or when a digest algorithm other than SHA1 is
used.”

 

 
Corollary
     to #5, SHA-1 is hardwired as the hash algorithm. Do we want an
     extensibility point here?

 

Regards,

 

 

Blake Dournaee

Senior Security Architect

Sarvega,
Inc.

http://www.sarvega.com/
← Prev in month ← Prev in thread
Next in thread → Next in month →