RE: Integrity Checking Requirement was -> RE: HW Support and XML Enc ryption Requirements

Good encryption & MAC schemes exist.

However there is no need to treat such a scheme any differently than an
encryption only scheme.

The argument I was making is that the encryption algorithm and MAC method
MUST be considered as a single unit. 

Note also that an authenticate & encrypt function is only valid if the
symmetric key is authenticated by the recipient. If the symmetric key is
simply recovered from an encrypted RSA blob there is no authenticity, the
message could be faked by anyone.

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Mike Wray [mailto:mjw@hplb.hpl.hp.com]
> Sent: Tuesday, February 27, 2001 5:36 AM
> To: reagle@w3.org
> Cc: jimsch5@home.com; pbaker@verisign.com; xml-encryption@w3.org
> Subject: Re: Integrity Checking Requirement was -> RE: HW Support and
> XML Enc ryption Requirements
> 
> 
> >From reagle@w3.org Mon Feb 26 15:12:54 GMT 2001
> Date: Mon, 26 Feb 2001 10:11:38 -0500
> >Well, we its now clear we need a requirement one way or the 
> other as this 
> >has come up in the past, most recently on January 8th [1]. Philip 
> >Hallam-Baker [2] and Jim Schaad [3] opposed this requirement 
> for the reasons 
> >in the referenced thread. Could you speak to the points they 
> raised? This 
> >issue is not captured in the requirements document [4].
> >
> >
> >[1] 
> http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0011.html
> >[2] 
> http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0014.html
> >[3] 
> http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0059.html
> >[4] 
> http://www.w3.org/Encryption/2001/01/23-xml-encryption-req#req
-integrity

BTW, Jim's message was
http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0060.html

Philip raised the issue that XML-Signature already allows MAC.
As I said in my earlier message, while this is true it is heavy
from an implementation point of view. In order to use XML-Signature MAC
you have to canonicalise your input, create an XML signature, add it to the
input, then canonicalise the result and encrypt it. In contrast,
if MAC is part of the cipher suite you canonicalise the input,
compute MAC, append MAC to the input bytes and encrypt.

If MAC is part of the cipher suite it is implemented over bytes,
and so can be done easily without extra XML processing.

Putting the MAC in the cipher suite makes the processing steps clear:
the MAC is checked after decryption and before releasing the content bytes.
If you use XML-Signature to add a MAC, then on decrypt you find a
signed XML doc and you have to know whether you are supposed to check the
signature (and remove it) before proceeding.

In addition, supporting cipher suites including MAC means you can
use XML Encryption without requiring an XML Signature implementation.

Philip discusses some problems with particular schemes.
It is true that bad schemes exist - good ones do too, so this is
not an argument against providing integrity checks,
For one thing what I have in mind is very much like SSL -
add a MAC specifier to the cipher suite.
Another point is that I would not envisage an unkeyed integrity
check, such as a simple checksum, since this is vulnerable to attack.
Any integrity check needs to be a keyed MAC. This is why I would
propose requiring HMAC-SHA1 or the like.

To be clear, the data transform including a MAC is

 dout = E(ke, din @ MAC(km, min))

 where
	din - data input
	dout- data output
	km  - MAC key
	ke  - encryption key
	@   - append on bytes (infix)
	MAC - MAC function
	E   - encryption function

This transform is used to avoid the kind of problems Jim mentions.

It is easy to creat integrity constructions that do not work, such as
the checksum+RC4 construction Philip describes. This is another
reason why it is good to provide integrity constructions without these
flaws - users can use these knowing they are OK and don't have to take
the risky step of doing their own thing.

Mike Wray (mike_wray@hp.com)