Subject: Re: ikev2-07: last nits

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 2 May 2003 16:54:23 -0700

At 11:51 PM -0400 5/1/03, [email-masked] wrote:
>I believe that the use of a prf other than HMAC (or at least not accepting
>a variable length key) is dangerously poorly thought out, and my
>inclination is to take out all references to it.

Fully agree.

>  Since it got added there
>have been a series of problems (including the one earlier in this note).

Here's more. Section 2.15 says:
     If the negotiated prf takes a fixed size key, the shared secret MUST
     be of that fixed size.

This is completely wrong. It means that the two sides need to know 
before they choose their preshared secret what the prf that they will 
negotiate every time will be.

>  I
>hadn't noticed - but you are certainly correct - that the spec assumes that
>if the prf has a fixed length key that the key length is the same as the
>output length. That allows AES128-CBC, but no others come to mind. We could
>keep patching, but is this really a requirement? It was motivated by people
>who were going to put AES in hardware and didn't want to have to implement
>a digest function as well. I'll buy that for the fast path (packet
>integrity checks), but do we really need to engineer for that case for the
>performance-irrelevant key expansion case? If so, could someone make a more
>specific suggestion as to how to fix this.

I support your original suggestion: prohibit prfs with fixed-size 
keys. If someone really wants to add one or more of them later, they 
can write an extension to IKEv2 that clearly specifies how to do it.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Subrata Goswami" <[email-masked]>
Date: Sat, 10 May 2003 08:52:25 -0700

Hi, I have submitted a new draft for using ESP in non-IP layers. The new
Internet-Draft version is available from the on-line Internet-Drafts
directories.

	Title		: Encapsulating Security Payload for Link Layers
(ESPLL)
	Author(s)	: Subrata Goswami
	Filename	: draft-goswami-ipsec-espll-00.txt
	
http://ietfreport.isoc.org/ids/draft-goswami-ipsec-espll-00.txt
	Pages		: 10
	Date		: 04-may-03
	
The trend has been to use different encryption mechanism for different
layers. Although it can be argued that encryption in multiple layers is
good protection, such an approach is highly inefficient from the point
of view of performance and necessity. In some situations this kind of
separate encryption mechanism may afford the bytes 7 levels of
encryption, for example : AES (from 802.11)+ 3DES (from IPSec) + 3DES
(from TLS/SSL).  Recently link layer encryption has become an important
issue, specially in the context of wireless networks. Although this
document does not attempt to solve this multiple layer encryption issue,
it is an effort to that goal. Specifically, this document describes a
way to use ESP in several link layer technologies.