Subject: Re: Crypto algorithms for IKEv2

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 28 Apr 2003 20:48:04 -0700

Offl-list, two people pointed out a serious typo. The document says:

>  For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12)
>  SHOULD be implemented. It is expected that in the not-distant future,
>  ENCR_AES_128_CBC (12) will become a MUST-level requirement and that
>  ENCR_AES_128_CBC (12) will become a SHOULD-level requirement.

The paragraph should read:
  For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12)
  SHOULD be implemented. It is expected that in the not-distant future,
  ENCR_AES_128_CBC (12) will become a MUST-level requirement and that
  ENCR_3DES (3) will become a SHOULD-level requirement.

That is, when we make AES a MUST, we will most likely demote 
TripleDES to a SHOULD. This is what we discussed on the mailing list 
and in San Francisco.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Tue, 29 Apr 2003 12:35:02 -0400

In regards to draft-hoffman-ipsec-algorithms-00-TEMP.txt, I notice that the 
UI ciphersuites make no mention of PFS. Are we assuming that this is an 
implementer decision?

Come to think of it, I don't think we ever resolved the issue of what to do 
when the initiator of a CREATE_CHILD_SA exchange doesn't propose PFS but the 
responder requires it. This could be accomplished with a 
NOTIFY_PFS_REQUIRED_ALWAYS or NOTIFY_PFS_REQUIRED_NEXT_SA message.

Not that we could really change it now, but did anyone consider the idea of 
acheiving PFS simply by applying a one-way hash to SKEYSEED_D, either 
periodically or after every CREATE_CHILD_SA exchange? Sure, there are race 
conditions, but I think they are easily fixed.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

---

From: Van Aken Dirk <[email-masked]>
Date: Wed, 30 Apr 2003 08:18:11 +0200

Hi Paul,

Looking at section 2.1 of your draft RFC or section 3.3 of the IKE draft, I
guess it is now possible to configure IKE with the NULL encryption algorithm
isn't it ?

I like this capability because I have now a simple means to perform low
level troubleshooting with tools such as Ethereal.
Wouldn't it be interesting to have a MUST implement or SHOULD implement
statement for IKE - NULL encryption ?
As such I can rely on this capability as different vendors will implement it
and will shorten troubleshooting interoperability issues.

Best regards - Dirk

2.1 Transform type 1: encryption algorithms

Name                 Number     Defined in
RESERVED              0
ENCR_DES_IV64         1         RFC 1827
ENCR_DES              2         RFC 2405
ENCR_3DES             3         RFC 2451
ENCR_RC5              4         RFC 2451
ENCR_IDEA             5         RFC 2451
ENCR_CAST             6         RFC 2451
ENCR_BLOWFISH         7         RFC 2451
ENCR_3IDEA            8         RFC 2451
ENCR_DES_IV32         9
ENCR_RC4             10
ENCR_NULL            11         RFC 2410
ENCR_AES_128_CBC     12
ENCR_AES_128_CTR     13