[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Determining the Order of Decryption and Signature Validation
Never mind that: according to 9.4 and 9.4.1 of the WSS: Soap Message Security-12, it should instead look like the example in section 9.1. Thanks, Thomas. -----Original Message----- From: DeMartini, Thomas Sent: Monday, April 21, 2003 12:50 PM To: Hal Lockhart; wss@lists.oasis-open.org Subject: RE: [wss] Determining the Order of Decryption and Signature Validation Can't you put the EncryptedData in the header and use the CipherReference inside that EncryptedData to refer to the actual encrypted bytes wherever they are in the message? Thanks, Thomas. -----Original Message----- From: Hal Lockhart [mailto:hlockhar@bea.com] Sent: Monday, April 21, 2003 12:20 PM To: wss@lists.oasis-open.org Subject: [wss] Determining the Order of Decryption and Signature Validation In a previous message: http://lists.oasis-open.org/archives/wss/200304/msg00015.html I identified an inconsistancy between different parts of the core spec relating to how a Receiver can determine the proper order to perform decryption and signature validation. It appears to me that there we have two choices: 1. The order of processing can be determined completely by the order of elements in the message. The use of the Decryption Transform is prohibited. 2. If a Decryption Transform is present, it must be used to determine the order of processing. Otherwise, the order of elements is used to determine the order of processing. To repeat what I said in my earlier message, this is not a security threat. The only consequences of incorrect order of processing is that signature validation will fail whan it should succeed. It also does not effect the ability to decrypt the data, although the question whether the data is authentic is another matter. Thus an attacker (or a buggy intermediary) can achieve nothing other than denial of service by reordering message elements. Although the spec currently seems to mostly specify choice #2, everyone I have talked to seems to feel that choice #1 would be preferable, if it can be achieved. The main reason is that if we chose #1, receivers will have to inspect every Signature to see if there are any Decryption Transforms present, which defeats the ability to process the message in one pass. There is also the complextity of supporting the transform. In order to make #1 possible, three things are required. 1. Any sender generating elements that are both signed and encrypted must be able to order the elements so as to indicate the correct processing order. 2. Any intermediary encrypting a portion of a message which overlaps with any existing encrypted or signed data in the message, must be able to order the elements so as to indicate that the decryption must precede the other operations, whether adding to an existing security header or creating a new security header (addressed to a different role). 3. Any intermediary signing a portion of a message which overlaps with any existing encrypted data in the message, must be able to order the elements so as to indicate that the signature verification must precede the encryption, whether adding to an existing security header or creating a new security header (addressed to a different role). It seems to me that this is not possible using the current specification. First let us be specific about what elements would be used to determine encryption and signature order. It seems that the order of security tokens will not do, because they may not be present at all or may be used by multiple operations. It would seem that the order of the EncryptedData and Signature elements should indicate the order of processing. But that will not always work, because the EncryptedData must appear where the cleartext was, which may be in the Body and the Signature must appear in the header. Interop scenario #3 solves this problem by putting the EncryptedKey before Signature in the header, but this will not always work. For example, suppose we are using a symmetric key, say with Kerberos. If we use it for both signature and encryption, I think we are ok, because I believe the hash must be over the cleartext, so the hash can be encrypted. However, suppose one party signs the body using a PK and then another party encrypts the data with a symmetric key contained in a Kerberos ticket, for example. How does the second party indicate that the data should be decrypted first? I haven't worked through all the possible combinations implied by the various kinds of KeyInfo, STR's and so forth. Can anyone see a set of rules which will let specify order without the need for the Decryption Transformation? Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]