Re: [ws-rx] Updated proposal for i121

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

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
>>