Re: [ws-rx] Updated proposal for i121

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Marc Goodner wrote:
> Thanks for the pointer.
> 

No problem.

> Regarding the charter, I don't agree with your interpretation. That
> interpretation to me would mean removing references to SOAP 1.1 and WSDL
> 1.1 on the grounds they are just contributed specs as well. 
>

I see the issue of SOAP 1.1 and WSDL 1.1 as an exception not the norm.
WSDL 1.1 and SOAP 1.1 has been treated differently, in various stds 
organization, than other specs. Sort of like how SSL is treated. I don't 
see WS-Policy, WS-Addressing, WS-SC, WS-Trust, WS-SecurityPolicy being 
treated the same way and I interpret the charter stmt to apply to those 
specs and not soap 1.1/wsdl 1.1.

-Anish
--

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Thursday, July 06, 2006 11:33 AM
> To: Marc Goodner
> Cc: Raepple, Martin; Gilbert Pilz; ws-rx@lists.oasis-open.org; Prateek
> Mishra
> Subject: Re: [ws-rx] Updated proposal for i121
> 
> Marc Goodner wrote:
>> inline
>>
>> -----Original Message-----
>> From: Raepple, Martin [mailto:martin.raepple@sap.com]
>> Sent: Thursday, July 06, 2006 4:45 AM
>> To: Gilbert Pilz; ws-rx@lists.oasis-open.org
>> Cc: Prateek Mishra
>> Subject: RE: [ws-rx] Updated proposal for i121
>>
>> <QUOTE>
>> I definitely welcome and specific proposals you may have on this issue
> 
>> but I'm not certain I agree with you. I had thought that, in general, 
>> once a block of information has been encrypted it is not possible to 
>> make any changes to the ciphertext without breaking the decryption 
>> process. Any attempts to decrypt the altered ciphertext will, at best,
> 
>> yield unintelligible junk or, as is more often the case, result in an 
>> some kind of run time error from the crypto engine. Therefore 
>> encryption gives you both confidentiality and integrity. Am I
> mistaken?
>> </QUOTE>
>>
>> To the best of my knowledge, there are certain block cipher modes
> (e.g.
>> CBC)
>> used in symmetric crypto algorithms that do ONLY provide 
>> confidentiality but do NOT protect the integrity of the encrypted
> data.
>> This means that an attacker (even without the knowledge of the key) 
>> may still be able to modify the encrypted data and the decryption 
>> process will still work without throwing any run time exceptions.
>> Therefore I think it is not best practice to use encryption as a means
> 
>> to protect integrity. Instead, message integrity should only be 
>> verified by (keyed) hash functions specifically designed to protect 
>> data integrity and
>> (optionally)
>> the authenticity of a message.
>>
>> MG: Can someone please refer me specifically to what text in the 
>> proposal this concerns? I recall there were sections that talked about
> 
>> encryption and integrity, is there a specific place where it says 
>> encryption provides integrity?
>>
> 
> lines 36-37 in the word version of the doc:
> "Integrity threats are generally countered via the use of digital
> signatures or encryption at some level of the communication protocol
> stack."
> 
>> <QUOTE>
>> (1) The section you are referring to appears (AFAICD) only in an 
>> editors draft. We can't go to public review with references to editors
> 
>> drafts in our document.
>> </QUOTE>
>>
>> If we follow this policy, then any of the existing references to 
>> WS-SecurityPolicy in the current proposal(s) are also affected, right?
>>
>> MG: We have to pick a version of these specs to reference. As the SX 
>> TC has not released any CDs yet it would seem to me the safest thing 
>> to reference would be the contributed versions.
> 
> Our charter says:
> "If an above specification is outside of a standardization process at
> the time this TC moves to ratify its deliverables, or is not far enough
> along in the standardization process, any normative references to it in
> the TC output will be expressed in an abstract manner, and the
> incarnation will be left at that time as an exercise in
> interoperability."
> 
> Given this, I don't think we can reference SC or SP unless they are "far
> along" in the process. That means we cannot normatively reference any
> contributed versions.
> 
>> So I would only see this as
>> a concern if we were referencing something that was in one version and
> 
>> not the other. I know of no such concerns with SP. With regards to 
>> this section of SC, Prateek mentioned the usage of the STR in a body 
>> is described in section 8. That section number is from the current SX 
>> TC version, the contributed version it was section 9. There have been 
>> no changes to that section from the contributed version, though as Gil
> 
>> points out in this thread the SX TC is looking at providing more 
>> advice to not use local references from the STR when possible. I think
> 
>> I can turn around another copy of the proposal for issues 122 - 124 
>> this morning that reflects these concerns as well as the previous note
> 
>> from Sanjay that the header must always be mU=true.
>>
>> <QUOTE>
>> My thinking was that a shared SC is a pre-condition to protecting a 
>> Sequence using WS-SC. How the RMS and RMD established that shared SC 
>> is out of scope of the WS-RM specification in the same way that the 
>> means and mechanisms for establishing an SSL/TLS session are out of 
>> scope as well.
>> </QUOTE>
>>
>> Yes, but one can think of RM-specific usage of the SC models which 
>> should be described in a security section of the RM spec. Prateek and 
>> I had a very productive side discussions on that and are working on a 
>> proposal.
>>
>> MG: I don't see the need for this. SC defines different ways to 
>> establish an SCT, I don't see why RM needs to further qualify any of 
>> those.
>>
>> Unfortunately, we won't be able to submit it before Monday 10th. 
>> Apologies to the TC for the delay, but I hope people will then have a 
>> chance to review it next week so that we can discuss it on the 7/13 
>> call.
>>
>>
>> - Martin
>>
>>> -----Original Message-----
>>> From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
>>> Sent: Donnerstag, 6. Juli 2006 02:06
>>> To: Prateek Mishra
>>> Cc: ws-rx@lists.oasis-open.org; Anish Karmarkar
>>> Subject: RE: [ws-rx] Updated proposal for i121
>>>
>>> Comments in line . . . 
>>>
>>>> -----Original Message-----
>>>> From: Prateek Mishra [mailto:prateek.mishra@oracle.com]
>>> [stuff removed]
>>>
>>>> (1) The connection between encryption and message integrity is 
>>>> misleading. TLS includes a message integrity check using HMAC (keyed
>>>> MAC) on a per-message basis. Use of encryption supports a 
>>>> confidentiality requirement not message integrity; all references to
> 
>>>> encryption should be removed from the draft (unless confidentiality 
>>>> is an additional
>>>> requirement) .  I can
>>>> propose alternative language in a change version of your draft.
>>> I definitely welcome and specific proposals you may have on this 
>>> issue but I'm not certain I agree with you. I had thought that, in 
>>> general, once a block of information has been encrypted it is not 
>>> possible to make any changes to the ciphertext without breaking the 
>>> decryption process. Any attempts to decrypt the altered ciphertext 
>>> will, at best, yield unintelligible junk or, as is more often the 
>>> case, result in an some kind of run time error from the crypto 
>>> engine. Therefore encryption gives you both confidentiality and
> integrity. Am I mistaken?
>>>> (2) I am troubled by prescriptive advice given on lines 184-186 that
> 
>>>> describes a specific technique for identifying a security token.
>>>> As we have discussed before, the requirement to connect a specific 
>>>> security  token to a specific message is a general requirement 
>>>> extending beyond RX. It would be much better if this text were  to 
>>>> make reference to Section 8 of WS-SC which describes this technique 
>>>> versus inventing it from scratch,
>>> There are a couple of problems with this:
>>>
>>> (1) The section you are referring to appears (AFAICD) only in an 
>>> editors draft. We can't go to public review with references to 
>>> editors drafts in our document.
>>>
>>> (2) The section you are referring to shows examples wherein SCT's are
> 
>>> referenced by local ID. Hal has made it clear to me that he does not 
>>> want to see this practice encouraged. I believe he has an issue open 
>>> on
>>> that in WS-SX.
>>>
>>> (3) Obviously WS-SX is going to move forward and the section you are 
>>> referring to will probably appear (in some form pending the outcome 
>>> of the issue noted above) in CDs, PRs, etc. The problem is that the 
>>> WS-SX TC is somewhat behind the WS-RX TC in the OASIS process. I 
>>> don't want to end up blocking the WS-RX TC waiting on the WS-SX TC to
> 
>>> get to a particular stage.
>>>
>>> Perhaps we could use our own description that will be forwardly 
>>> compatible with what WS-SC will eventually say on the matter?
>>>
>>>> (3) Lines 189-192 state:
>>>> [quote]
>>>>
>>>> For the lifetime of the Sequence the RM Source and the RM
>>> Destination
>>>> use the session key(s) associated with the security context
>>> to either
>>>> sign or encrypt (as defined by WS-Security) at least the
>>> body and any
>>>> relevant WS-RM-defined headers of any and all messages or
>>> faults that
>>>> refer to that Sequence.
>>>>
>>>> [\quote]
>>>>
>>>> The reference to encryption should be removed.  Is it also possible 
>>>> to explicitly list the headers  that must be signed?
>>> See my previous comments on encryption.
>>>
>>> I think explicitly listing the headers is a good idea. The only 
>>> problem
>>> is the treatment of the headers that can be piggy-backed. They need 
>>> to be signed but the signature doesn't necessarily need to cover the 
>>> body of the message. In fact, there may be cases in which there is no
> 
>>> body to sign. Perhaps a table . . .
>>>
>>>> (4) Finally, Section 3 of WS-SC describes different models for 
>>>> establishing a shared SC. Should this specification offer advice on 
>>>> the models supported by a RM source and destination? Are all three 
>>>> models supported?
>>> My thinking was that a shared SC is a pre-condition to protecting a 
>>> Sequence using WS-SC. How the RMS and RMD established that shared SC 
>>> is
>>> out of scope of the WS-RM specification in the same way that the 
>>> means and mechanisms for establishing an SSL/TLS session are out of 
>>> scope as well.
>>>
>>> - gp
>>>