> 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:]
>> Sent: Donnerstag, 6. Juli 2006 02:06
>> To: Prateek Mishra
>> Cc: ; Anish Karmarkar
>> Subject: RE: [ws-rx] Updated proposal for i121
>>
>> Comments in line . . .
>>
>>> -----Original Message-----
>>> From: Prateek Mishra [mailto:]
>> [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
>>
>
