[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wss] Web Services Security Username Token Profile
At 09:27 AM 1/30/2003, ronald monzillo wrote: >Ahmed, Zahid wrote: > >>Ron, >> >>Please see previous e-mail as response to Gene. >> >> >> >>>So for me, the key form used with usernametoken based data origin >>>authentication is more a funtion of what the end system is capable of >>>doing, than it is what the processing model is. If the authentiction >>>interfaces of the end system do not make it >>>possible for the signature validator to get access to either the actual >>>password value, or to acquire a password derived key, then we are likley >>>stuck with sending an encrypted >>>password. Otherwise sending key derivation parameters, would likley be >>>better. >>> >Ahmed, > >My thanks to you and others for pushing this thread along. > >I do have some concerns about the token (with pasword) only use case, >but I agree it needs to be supported. It seems to me that this use case is >dependent on some form of purpose labeling/configuration other than >what we have agreed to hang off STR's. My proposal for an XMLSecurityToken is directly aimed at solving the issue raised in this email about how to attach usage information to a token. Rather than attach the usage information to an STR you would wrap the password token in an XMLSecurityToken element in which the usage information would also be specified. >By this I mean, there may need to be a way for the provider of such a token to >indicate its intended purpose, as I believe the current "message" processing >model focuses on the validation of signature and encryption blocks. The >processing model for tokens by themselves is less obvious. It may be possible >to drive the "token" processing model from the back, that is, the recipient >requires such a token, and knows what it plans to do with it. Although it >would seem hard to believe that a recipient would know what to do with >such a token without a policy for requiring one be sent to it. > >I think the PBE/PBS use case likely creates a new requirement on STR's; >that they be able to be used to reference an encrypted (username)token >containing a cleartext password. Perhaps I am wrong on this. > >Can anyone suggest how an STR in keyInfo can be used to reference a >password inside an encrypted username token? > >Perhaps there is an alternative approach to doing the same thing (I view >the use of a password derived key (which I don't think requires encryption >of the key), as a different case. > >Ron > >PS: This reminds me I thought we had an open issue relating to purpose >labeling; >that is the specifc purpose values. > > >>Thanks for this explanation. My take is that if end-point >>WS-Security enabled application does not care to validate >>signature but just validate the password (due to availability >>of secure transport), then it would be useful to distinguish between the >>basic password token and its variant, the securely binded password token. >>This may help us w.r.t. interops >>possibly. >> >>thanks, >>Zahid >> >> >> >> >>-----Original Message----- >>From: ronald monzillo [mailto:ronald.monzillo@sun.com] >>Sent: Wednesday, January 29, 2003 1:57 PM >>To: Ahmed, Zahid >>Cc: 'Web Services Security' >>Subject: Re: [wss] Web Services Security Username Token Profile >> >> >>Zahid, >> >>I don't understand your concern about using other than DSA and RSA keys as it >>would seem to also preclude the Kerberos token binding. >> >>All of our token profiles suggest that they be used (perhaps among other >>uses) >>to convey a key to support a signing or encryption operation; most >>notably to achieve data origin authentication in the presence of >>intermediaries. >> >>If you are advocating another form of data origin authentication, not >>based on >>signatures, then I would think you would still want to use the security token >>to convey the key, and I think you would still need something to convey to >>what parts of the message the data origin was bound. IMV, the SignedInfo >>component of signature should be used for the latter purpose. >> >>It seems to me that perhaps the only important use model for passwords is >>the case >>where you need to get a password all the way through to some end system >>that doesn't accept anything else but a password, and you want to make >>sure that it is the only place that >>will be able to see the password. Even in this case, you likely want to >>use the password >>to sign the msg (as in with a signature) >> >>So for me, the key form used with usernametoken based data origin >>authentication >>is more a funtion of what the end system is capable of doing, than it is >>what the >>processing model is. If the authentiction interfaces of the end system do >>not make it >>possible for the signature validator to get access to either the actual >>password value, or >>to acquire a password derived key, then we are likley stuck with sending >>an encrypted >>password. Otherwise sending key derivation parameters, would likley be >>better. >> >> >>Ron >> >> >>Ahmed, Zahid wrote: >> >> >> >>>Generally, I don't think it is a good idea to coerce Password tokens >>>to behave like other types of tokens that require proof of possession >>>or evidence of holding the (signing) key. >>> >>>I do, however, appreciate the motivation of securely binding the >>>Password token to a part of SOAP message such that we can >>>protect the integrity of token association with the message indepedent >>>of the transport protocol used to transmit the SOAP message. >>>We can also argue that encryption of password is required >>>independent of transport security. However, in practice, the SSL/TLS >>>transport is sufficient in both of these problem domains. >>> >>>I'm also concerned that we do not want to generate signature using >>>PBE algorithm (using the Password in Password token) if it will imply >>>not being compatible with W3C XML Signature which specifies use of >>>DSA (required) and RSA algorithms (optional). >>> >>> >>>Perhaps we could consider this as new token profile, but keep the >>>basic password token profile scope as is. >>> >>>thanks, >>>Zahid >>> >>>-----Original Message----- >>>From: Gene Thurston [mailto:gthurston@amberpoint.com] >>>Sent: Wednesday, January 29, 2003 12:10 PM >>>To: 'Web Services Security' >>>Subject: RE: [wss] Web Services Security Username Token Profile >>> >>> >>> >>>Colleagues, >>> >>> >>> >>>[.......] >>> >>> >>> >>>(General) Discussion: Overall, while I think that this token profile will >>>be widely used (perhaps the first one to be widely used, since folks are >>>generally familiar with, and have large databases of, username/password >>>pairs), I see that its main weakness is the lack of binding the token to >>> >>the >> >> >>>message "request" or "response" (that is, some part of the message body >>>which represents what the username is "saying". While it is true that >>> >>using >> >> >>>a secure transport (such as HTTP over SSL) can provide this, there is an >>>alternative approach, which in some sense fits in better with the overall >>>WS-Security processing model of using signatures to provide this "binding". >>>(Of course, signatures also provide evidence of the "claims" asserted by >>> >>the >> >> >>>presence of various tokens.) So, I think another profile here, surrounding >>>the Username token goes something like this: >>> >>>* Username token only carries the username. (The implicit claim >>>here is that the user named is the "sender", I suppose.) >>> >>>* A signature is included using a PBE algorithm, and signs that >>>portion of the body that the "sender" is stating ... typically, the message >>>Body. >>> >>>* The signature may also sign the timestamp header (described in >>>Appendix A of the Web Services Security: SOAP Message Security >>>specification) to combat replay attacks. (Side note: Shouldn't we add a >>>general <wsu:Nonce> element as a header which can be used by *all* types of >>>tokens?) >>> >>>* The <ds:KeyInfo> element of the signature will use a >>><wsse:SecurityTokenReference> to the Username token. >>> >>>* The "key" associated with that token will be generated based on >>>the mutually shared secret password (or equivalent) using a standard PBE >>>algorithm. >>> >>>It seems to me that the user interaction in this scenario will still look >>>the same: Need a username and password. But, that the processing model is >>>now a lot more consistent with the other kinds of security tokens we expect >>>to see. Basically, while I don't believe we have come right out and said >>>so, I think *all* of the token types we have considered can be thought of >>> >>as >> >> >>>"Key Holders" ... either a key is explicitly embedded in the token (ala, >>>X.509 certificates), or a key is somehow implicitly represented or can be >>>generated. Am I way off base here? >>> >>> >>> >>> >>> >>>That's about it. Thanks for playing! >>> >>> >>> >>>- Gene Thurston - >>> >>>AmberPoint, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Anthony Nadalin [mailto:drsecure@us.ibm.com] Sent: Tuesday, >>>January 28, 2003 6:33 AM >>>To: Web Services Security >>>Subject: [wss] Web Services Security Username Token Profile >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>Here is the UsernameToken update that Phil created it was edited to be in >>> >>>line with the WSS-Core-09 update. >>> >>>(See attached file: WSS-Username-11.pdf) >>> >>> >>> >>>Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 >>> >>> >>>---------------------------------------------------------------- >>>To subscribe or unsubscribe from this elist use the subscription >>>manager: <http://lists.oasis-open.org/ob/adm.pl> >>> >>> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC