Subject: Re: [MSEC] Consensus call on draft-ietf-msec-ipsec-signatures-05.txt

From: George Gross <[email-masked]>
Date: Wed, 1 Jun 2005 12:44:41 -0400 (EDT)

Hi Brian,

I have one clarifying question inline below; in all other regards this
draft is ready for movement to RFC...

br,
	George

On Tue, 31 May 2005, Lakshminath Dondeti wrote:

<snip>
>
> 5. Section 4.0 contains new text on combined modes and states in part
> "The RSA signatures algorithm cannot be used with an ESP Combined Mode
> algorithm that includes an explicit ICV."
>
> There is an explanation as to why.

I looked at this section, and it wasn't immediately obvious why there was
this restriction, x'cus me if this is a dense question ;o)

Why could you not define an ESP header/trailer that has both the ESP
Combined Mode algorithm ICV and the RSA signature authenticator, and do
the combined mode's authenticate/encrypt payload processing with the RSA
signature data field set to zero? After the sender executes ESP Combined
Mode, it then computes the RSA signature, and fills in the zeroed field
with the signature data. On the receiver side, reserve a copy of the
signature data, zero fill the signature data field, then apply ESP
Combined Mode decryption and group authentication verification. If the
group authentication passes, then proceed to do RSA signature
verification on the original (i.e. encrypted) ESP payload that had been
signed.

<snip>

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Brian Weis <[email-masked]>
Date: Wed, 01 Jun 2005 22:10:45 -0700

Hi George,

> draft is ready for movement to RFC...

Thanks for the feedback on this. One clarifying comment at end.

> verification on the original (i.e. encrypted) ESP payload that had been

What you describe seems very feasible to me. However, in my opinion 
that's a bit more definition than should be found in a single transform 
document such as this. I.e., perhaps such a description would belong in 
some definition of ESP. Since ESP currently doesn't allow the ICV field 
to be used by two transforms, I expect that it would have to describe 
how the two transforms interact (which you've documented above). That's 
the heart of the change -- defining how the transforms interact, which 
is an ESP issue.

So in the absence of the ESP modification, I was advised to put in a 
comment saying that this transform won't work with such a combined 
transform.

Thanks,
Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 02 Jun 2005 08:14:06 -0400

Hi George,

That is a good question, especially since I asked the same question 
:-).  But, Brian is right (and I think Steve Kent or Sam Hartman who 
pointed this out are too).  The ESPv3 definition is what it is today.  
Within that scope, we cannot put two ICVs into one field.  If and when 
we define a multicast ESP, we can rewrite that part of the spec.

thanks and regards,
Lakshminath

Brian Weis wrote:

> that's a bit more definition than should be found in a single 
> transform document such as this. I.e., perhaps such a description 
> would belong in some definition of ESP. Since ESP currently doesn't 
> allow the ICV field to be used by two transforms, I expect that it 
> would have to describe how the two transforms interact (which you've 
> documented above). That's the heart of the change -- defining how the 
> transforms interact, which is an ESP issue.
>

---

From: George Gross <[email-masked]>
Date: Thu, 2 Jun 2005 05:07:39 -0400 (EDT)

Hi Brian,

	ok, your explaination makes the origin of the restriction clearer.
it sounds like the way around the restriction is to nest ESP within ESP.
The outer ESP being combined mode encryption and group authentication and
the inner ESP being RSA signature authentication with null encryption. I
noticed that section 6.7 already talks about this option.

If you think that it makes sense, would you mind adding a sentence
pointing to this workaround option in that section?  That would soften the
restriction on AES-GCM or AES-CCM, albeit with some ESP overhead.

thx,
	George

---

From: Brian Weis <[email-masked]>
Date: Mon, 13 Jun 2005 15:22:22 -0700

Hi Sam,

Sam Hartman wrote:
> If you do talk about nesting ESP within ESP, make sure that your
> description is 2401bis-centric not 2401-centric.  IN particular, under
> 2401bis you would need to send a packet across the protection barrier
> twice (something not all implementations will support); you only get
> one decapsulation/encapsulation for each transition.

Thanks for the reminder. I believe that it is still possible within 
2401bis to specify a pair of  AH and ESP transforms as a single policy. 
E.g., (AH with an HMAC) and (ESP with RSA signatures). This would not 
cause the extra trip across the protection barrier. Do you agree?

Thanks,
Brian