RE: [ws-rx] Updated proposal for i121

["Marc Goodner" <mgoodner@microsoft.com>]

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?

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