Re: [soa-rm-ra] WS Trust

[Francis McCabe <frankmccabe@mac.com>]

Right now, this stuff looks both too low level and missing the larger  
point.

Some random responses
1. the current efforts in message security are focusing on actually  
reading the communications to make sure that policies are being  
complied with (e.g., no discussion of ira* in public) This gets  
around the problem of a properly signed message containing stuff that  
it should not.
2. Real trust is a function of who you are and what you are trying to  
do. I.e., you cannot separate out the roles from the action.
3. We made the decision some time ago not to make technology choices.

Frank

On Dec 7, 2006, at 10:06 AM, Chiusano, Joseph wrote:

> In case it helps, here is an excerpt from a March 2003 article that  
> I wrote on WS-Trust - though the spec has changed since then, I  
> think if you look at the description I provided below, most if not  
> all of the concepts can be applied to the figure that Duane  
> provided. The figure below is my own, as there was no such figure  
> in WS-Trust at the time.
>
> Joe
>
> P.S. My other choice was to send you a very short block of Word Art  
> with the word "voiceover".;)
> Managing Trust Relationships: WS-Trust
> All of the concepts discussed to this point are highly important,  
> but they cannot be useful unless there is a trust relationship  
> between two parties. This is the focus of WS-Trust specification,  
> released in December by 2002 by Microsoft, IBM, Verisign, and RSA  
> Security.
>
> Trust Engine/Security Token Service
> WS-Trust introduces the notion of a trust engine, a conceptual  
> component of a Web service that evaluates the security-related  
> aspects of a message. A trust engine verifies that:
>
> The claims in a security token are sufficient to comply with the  
> policy and that the message conforms to the policy.
> The attributes of the claimant are proven by the signatures.
> The issuers of the security tokens are trusted to issue the claims  
> they have made.
> For example, if a policy stated that only Kerberos tickets were  
> accepted as a security token, the trust engine of a Web service  
> would enforce this requirement for all incoming messages. The WS- 
> Trust specification also introduces the notion of a security token  
> service that issues security tokens based on trust, similar to a  
> certificate authority (CA).
>
> The figure below depicts a "sender" and "receiver" Web service,  
> each with its own trust engine. A security token service is also  
> depicted, from which the sender Web service will request a security  
> token to be used for its interaction with the receiver Web service.  
> The sender Web service can request a security token based on the  
> receiver Web service's policies, using the mechanisms described  
> earlier in this article. The sender Web service will use its trust  
> engine to authenticate the security token service, while the  
> receiver Web service will use its trust engine to authenticate the  
> sender Web service.
>
>
>
> XML Example: Security Token Request/Response
> The following example demonstrates a request for a security token  
> (X.509 certificate), and the response with the certificate. The  
> <wsse:BinarySecurityToken> was seen earlier in the description of  
> the WS-Security specification.
>
> <wsse:RequestSecurityToken> <wsse:TokenType>wsse:X509v3</ 
> wsse:TokenType> <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>  
> </wsse:RequestSecurityToken> <wsse:RequestSecurityTokenResponse>  
> <wsse:RequestedSecurityToken> <BinarySecurityToken  
> ValueType="wsse:X509v3"                           
> EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... </ 
> BinarySecurityToken> </wsse:RequestedSecurityToken> </ 
> wsse:RequestSecurityTokenResponse>
> In the above example, the <wsse:RequestType> element value of  
> "ReqIssue" denotes the issuance of a security token. Other valid  
> values are "ReqValidate" (validate security token) and  
> "ReqExchange" (exchange security token).
>
> Challenges
> In some cases, a security token service may choose to challenge the  
> requestor of a security token. For example, this may occur if the  
> security token service does not trust the nonce and timestamp (for  
> example, the freshness) in the message. Or, the security token  
> service may challenge the signature within the message. Challenge  
> requests and responses are issued by specifying challenge and  
> response elements within a <wsse:RequestSecurityTokenResponse>  
> element, in a negotiation-type scenario.
>
> XML Example: Signature Challenge
> Signature challenges are processed using the <wsse:SignChallenge>  
> element, as shown in the following example:
>
> <wsse:SignChallenge> <wsse:Challenge>Describes the message parts to  
> be signed...</wsse:Challenge> <wsse:SecurityTokenReference>...</ 
> wsse:SecurityTokenReference> </wsse:SignChallenge>
> The <wsse:Challenge> element in the above example uses one of two  
> possible mechanisms to describe the message parts to be signed:  
> either an XPath expression, or one of several "message part  
> selection functions" that are defined in the WS-PolicyAssertions  
> specification. The <wsse:SecurityTokenReference> element is used to  
> reference security tokens that are passed as part of the  
> negotiation process. Once the sender receives this challenge, they  
> would normally create a new signature that includes the specified  
> message parts and return the new signature in a  
> <wsse:SignChallengeResponse> element.
>
> Specification Location
> The WS-Trust specification can be found at http:// 
> msdn.microsoft.com/ws/2002/12/ws-trust.
>
>
> Joseph Chiusano
> Associate
>
> Booz | Allen | Hamilton
> 700 13th St. NW, Suite 1100
> Washington, DC 20005
> O: 202-508-6514
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
>
> From: Ken Laskey [mailto:klaskey@mitre.org]
> Sent: Thursday, December 07, 2006 12:54 PM
> To: Duane Nickull
> Cc: soa-rm-ra@lists.oasis-open.org
> Subject: Re: [soa-rm-ra] WS Trust
>
> A short voiceover?
>
> On Dec 7, 2006, at 12:44 PM, Duane Nickull wrote:
>
>> I would like to encourage the use of the WS-Trust model as part of  
>> the
>> security aspects of the RA.  The model is attached.
>>
>> Duane
>> -- 
>> **********************************************************
>> Sr. Technical Evangelist - Adobe Systems, Inc.           *
>> Chair - OASIS SOA Reference Model Technical Committee    *
>> Blog: http://technoracle.blogspot.com                    *
>> Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
>> **********************************************************
>>
>> <Picture 1.png>
>
>
> ---------------------------------------------------------------------- 
> --------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:        703-983-1379
> McLean VA 22102-7508
>