Re: [ws-rx] Updated proposal for i121

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

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

Given this, I would like to suggest that we defer the discussion of 
122-124 till next week when we have this proposal available on the ML.

-Anish
--

Raepple, Martin wrote:
> <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.
> 
> <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?
> 
> <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. 
> 
> 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
>>
>