RE: [ws-sx] issue 003: use of the term binding in SecurityPolicy

["Martin Gudgin" <mgudgin@microsoft.com>]

Prateek,

Thanks for the response. My comments are inline prefixed with [MJG].

Regards

Gudge

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> Sent: 06 February 2006 22:29
> To: Martin Gudgin
> Cc: ws-sx@lists.oasis-open.org
> Subject: Re: [ws-sx] issue 003: use of the term binding in 
> SecurityPolicy
> 
> Hi Martin,
> 
> Responses to your note are delimited by XML style delimiters with my 
> <initials>
> 
> >
> >Regarding Security Binding Property, I note that the title 
> of Section 6
> >(line 1242) is 'Security Binding Properties'.
> >  
> >
> <PM>  Agreed, this section does describe properties of security 
> bindings. </PM>

[MJG]
OK. Sounds like we are in agreement here.

> 
> >Regarding Security Binding Property Assertion, I note that several
> >assertions in section 7 indicate that they set property values, e.g
> >lines 1514, 1517, 1584, 1587, 1590, 1592, 1594, 1596, 1598 et.al.
> >
> >  
> >
> <PM>  My comment is  that the term "Security Binding Property 
> Assertion" 
> does not occur in anywhere
> in the text. So I am not really sure it helps when reading 
> the document.
> 
> It is interesting to note that all of the usages
> you cite take the form "Such-and-such assertion populates the 
> following 
> property" or "this assertion sets the following
> property to true". I would leave it up to the TC if they feel 
> this term 
> should be retained as it does not receive any use.
> </PM>

[MJG]
I guess my reasoning was that given we had a section called Security
Binding Properties, assertions that set those properties would naturally
be known as Security Binding Property Assertions. However, if the TC
wants to remove the term, I'm not too concerned.

> 
> >Regarding the proposed change at line 228, I think this change is OK,
> >although I'm not certain quite how it differs materially from the
> >existing text. Please could you clarify what it is you think 
> is allowed
> >and/or precluded by your proposed text vs the existing text?
> >  
> >
> <PM> I could not follow what was meant by "minimum set of tokens that 
> will be used"; is there also a
> "maximum set of tokens"? If so, how/where is this set described?
> 
> This point is mostly editorial so I will leave it at that.</PM>

[MJG]
Ah, I think I see the difference. My understanding is that
WS-SecurityPolicy defines the minimum (security) requirements for
communicating with the service. Clients may choose to do more than the
minimum. Some services might accept messages that do more than the
minimum. Some might not. For example, with respect to tokens, the
service might state a requirement for, say, a Kerberos Protection Token,
the client may choose to also provide some form of supporting token.

> 
> >Regarding the proposed change at line 229, I believe an encrypted key
> >token from WSS 1.1 would be such a mechanism. For example, Symmetric
> >binding with an X509TOken as the [Protection Token].
> >  
> >
> <PM> The standard term for this is "Key Transport" and not "Key 
> transfer". I would prefer we use the former.
> </PM>

[MJG]
OK. So the bullet at line 229 should read;

	"Any necessary key transport mechanisms"

> 
> >Regarding the proposed change at line 230, did you mean add 'in the
> >wsse:Security header'? If not, I don't think I understand 
> the proposed
> >change.
> >  
> >
> <PM> Yes, your reading is what I meant. </PM>

[MJG]
Great. So the new text (at line 230) should read;

	"Any required message elements (e.g. timestamps) in the
wsse:Security header."


> 
> >Regarding the proposed change at line 233, I'm inclined to 
> agree as the
> >signature confirmation aspect of an exchange is covered by the WSS11
> >assertion.
> >  
> >
> <PM> My concern was that "correlation of messages" could be 
> interpreted 
> much more broadly to topics covered
> under reliable messaging or other messaging protocols</PM>

[MJG]
OK. Sounds like we should remove this bullet (line 233) then.

> 
> >Regarding the proposed additional text, would 'canonicalization' be
> >better than 'normalization'?
> >
> >  
> >
> <PM> Yes, that would improve the proposed text </PM>

[MJG]
Great. So we should add a new bullet after line 232 that reads;

	"Various parameters, including those describing the 
	algorithms to be used for canonicalization, signing and
encryption."

> 
> >Cheers
> >
> >Gudge
> > 
> >
> >  
> >
> >>-----Original Message-----
> >>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> >>Sent: 27 January 2006 18:46
> >>To: ws-sx@lists.oasis-open.org
> >>Subject: [ws-sx] issue 003: use of the term binding in 
> SecurityPolicy
> >>
> >>At the F2F, I had asked a question about the use of term security 
> >>binding in Security Policy
> >>and as to what was intended by use of this term. My 
> comments here are 
> >>limited to this issue.
> >>
> >>The policy document does include a definition for this term 
> >>in Section 
> >>1.4, 2.3 (definition
> >>at an abstract level) and a more precise definition for 
> >>security binding 
> >>assertion in Section 7.
> >>
> >>(1) The terms Security Binding Property and Security 
> Binding Property 
> >>Assertion are defined in lines 76 and 79-80
> >>but not otherwise used elsewhere. I would suggest these terms 
> >>be removed.
> >>
> >>(2) proposed changes to Security Binding defiinition (Section 2.3)
> >>
> >>lines 227 - 234 provide a detailed definition of binding. I would 
> >>propose the following changes:
> >>
> >>line 228: replace by "The set of acceptable tokens and the means of 
> >>their binding to messages"
> >>
> >>line 229:  I dont see any "key transfer" mechanisms described 
> >>in any of 
> >>the bindings. In any case, I dont
> >>understand what "key transfer" means and it isn't listed in 
> >>my copy of 
> >>the handbook of applied crypto.
> >>
> >>line 230: Add "in the SOAP header"
> >>
> >>line 233: Delete. I dont believe any of the bindings 
> >>described in this 
> >>document provide this facility.
> >>
> >>Add new line: Various parameters, including those describing the 
> >>algorithms to be used for normalization, signing and encryption.
> >>
> >>--------------------------------------------------------------
> >>-----------------
> >>prateek
> >>
> >>
> >>    
> >>
> >
> >  
> >
> 
> 
>