Subject: LAST CALL: IKE Crypto documents I-D's

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 11 Jun 2003 08:06:15 -0400

This is a working group last call for comments on the following drafts.

For progression to Proposed Standard: 

	draft-ietf-ipsec-ikev2-algorithms-02.txt

For progression to Informational:

	draft-ietf-ipsec-ui-suites-00.txt

This last call with expire on June 23rd.

					- Ted and Barbara

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 12 Jun 2003 17:58:53 +0200

It's good that we're getting there, but I still think we haven't addressed
the issue of AES and key sizes.

The algorithms draft refers only to AES-128.  We should either add AES-256
or else rename the transforms to simply "ENCR_AES_CBC" and "ENCR_AES_CTR"
and use the keylength attribute to determine the specific "flavor" or AES.

IMO it doesn't make sense to use "ENCR_AES_128_CBC" with a 256-bit key.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Theodore Ts'o
Sent: Wednesday, June 11, 2003 2:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: LAST CALL: IKE Crypto documents I-D's

					- Ted and Barbara

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jun 2003 22:22:50 -0400

In anticipation of several proposed changes to RFC 2401, I would like 
to suggest a few additional payloads to be added to IKE v2.

Several folks have asked for the ability to place traffic with 
different TOS values on different SAs, which requires that the TOS 
field (IPv4) and the flow spec field (IPv6) be useable as selectors. 
If we agree to add this feature, we need the ability to negootiate 
this in IKE.

A few folks have observed that the current mandate for black side 
fragmentation poses DoS vulnerabilities for receivers. Thus we may 
choose to allow (or recommend) red side fragmentation. If so, we need 
to be able to negotiate use of this capability on a per-SA basis, and 
to notify the receiver that NO black fragments should be accepted, 
because none will be sent on this SA.

As a separate matter, I had requested a few months ago that we allow 
IKE peers to negotiate use of groups other than the set defined in 
Oakley. I see that there is a provision to negotiate other choices 
for P, but not for G. I apologize for not noticing this sooner. I 
would like to see the negotiation made more general, so that both the 
generator as well as the exponent are values that peers can negotiate.

Thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jun 2003 13:33:49 -0400

>In anticipation of several proposed changes to RFC 2401, I would 
>like to suggest a few additional payloads to be added to IKE v2.

Paul Hoffman sent me a nice, private note suggesting that I needed to 
do a much better job of describing, and motivating the changes I 
suggested.  He's absolutely right. And, while I was away on a 
business trip (after my vacation caused me to miss most of the last 
call comment period), David Black provided excellent clarification 
for one of my suggestions.  So, let me try again.

>If we agree to add this feature, we need the ability to negootiate 

What I meant to say is what David said in his message, i.e.:

That would be the 6 bit DS Field, as defined in RFC 2780.  The other
two bits in the same header octets are used for ECN and should not be
used as selectors.  There are some subtle issues in QoS specification
across administrative domain boundaries - in full generality, the
DiffServ Code Point (DSCP) values used in the DS Field do not have
global validity or meaning.

It's ok to use DSCPs when the values are only expected to be
meaningful to one end of the connection (e.g., receiver tells
sender to set DSCP to <x> in inner IP header for tunnel mode
SA), or something in the middle can be expected to do the
translation if necessary - the latter does not apply to IKE
for obvious reasons.  For more general negotiation, where both
ends are expected to understand what is being negotiated,
PHBIDs (RFC 3140) are appropriate.

At least this covers the IPv4 case.  I'm open to suggestions from 
IPv6 experts about what to do there, for flows.

Radia also comment on this issue, but I have to disagree with her a 
bit; I think it is important to allow the initiator to specify the 
intent to segregate traffic by the DS field, e.g., to try to get the 
responder to treat return traffic accordingly.

Thinking ahead, we ought to decide if there are other fields we want 
to specify as selectors, now. For example, we've had discussion on 
the list about using ICMP message type fields in lieu of port fields, 
when ICMP was the payload.

>choose to allow (or recommend) red side fragmentation. If so, we 
>need to be able to negotiate use of this capability on a per-SA 
>basis, and to notify the receiver that NO black fragments should be 
>accepted, because none will be sent on this SA.

My terminology here was sloppy, relative to what we usually use in 
IPsec. Today, we require an IPsec implementation to fragment a packet 
after processing, if we increase its size beyond the MTU for the link 
via which the packet is being transmitted from the IPsec 
implementation. This creates a problem for a receiver, because an 
attacker can create what appear to be legitimate, non-initial 
fragments and cause reassembly problems. If we allowed a sender to 
fragment a packet prior to IPsec encapsulation, then we could avoid 
this problem. So, I was suggesting that we add a paylod to IKE to 
allow an initiator to indicate the intent to perform such 
fragmentation on an SA, with the ability of the responder to indicate 
whether this is OK (i.e., it knows how to manage the reassembly after 
IPsec decapsulation), or not (the status quo). An acceptance by the 
responder would imply that it could choose to do the same for the 
companion SA.

A logical, but separable, companion to this feature is to allow the 
initiator to request  the responder to accept fragments on an SA 
where port fields are used as selectors.  The issue here is that a 
host may send fragments to an IPsec device that requires port field 
examination for the SA to which the fragments will be mapped. It 
seems reasonably safe to allow fragments (with a suitable., minimum 
offset) to pass through such as SA, with only the initial fragment 
having the port fields examined. This is a separate negotiation 
because the fragments arise from hosts behind the IPsec device, but 
it is related, because if one fragments at the sending IPsec device, 
it would be nice to be able to use this feature to allow the receiver 
to pass on fragments, not reassemble them (in the case of a SG).

>would like to see the negotiation made more general, so that both 
>the generator as well as the exponent are values that peers can 
>negotiate.

This is a request to make the IKE parameter space negotiation more 
flexible. there would be no requirement that a conforming 
implementation support other groups than the ones defined in the 
separate IKE algorithms spec. But it would allow user communities to 
specify other groups for their own use. I thought we agreed on this a 
while ago, but I didn't check closely enough to realize that the 
current IKE version allows only the exponent, not the generator, to 
be specified. My intent had been to allow both to be specified.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 24 Jun 2003 20:11:21 +0300

> be specified. My intent had been to allow both to be specified.

This is one of the features of the IKEv1 that I would really like to
be removed from IKEv2. The problem with private diffie-hellman groups
is that you do now know how the group was generated, and is it safe.
If you try to do online checks for the groups it takes time and adds
more code to the ipsec, causing more bugs.

I do know this, as I did implement that feature in the IKEv1.

We do have 16-bit number for groups. We do have private use space for
groups to be used. I suggest we remove the options to negotiate any
group parameters inside the IKE, and say that if you want to use other
groups, you either

	1) write a document describing the groups, and allocate
           proper number for them from IANA.

	or

	2) Define the group parameters in both ends and take number
           from private use space and use that ine IKE.

In that case the adminstrator can do all verifications it wants when
allowing the group to be used.

If someone really wants to have new groups to be automatically
generated every day and use them in the IKE, they can defined their
own protocol how to move those group descriptions from one IKE peer to
the other, before starting the use them in IKE (i.e http-post of
signed group description config file :-)

Ups, the transform ID field is now only 8-bits, thus we can only have
255 different groups, but there is 16-bits of RESERVED before that,
thus we could very easily extend it to the 24-bit number, thus having
definately enough different groups...

So, my suggestion is to:

	1) modify the Transform ID field to be 16-bits.

	2) Remove Transform type 4 (Diffie-Hellman Group) Transform
           ID numbers 201-203, and the text describing anything about
           them.

	3) Fix the text in the 3.3.5 saying that only thing that use
           attributes are when we define our own Diffie-Hellman
           groups, to say that only thing that actually uses the
           attributes are the ciphers having different key lengths
           (i.e AES).

	4) Remove all "Group *" attribute types, and also the Field
           Size attribute type.

	5) Remove text in the 3.3.6 Attribute Negotiation about the
           defining the groups on the fly. 

	6) Extend the DH Group # in the Key exchange payload to be 16
           or 24 bites as the Transform ID also is made bigger.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 Jun 2003 22:32:36 -0400

>more code to the ipsec, causing more bugs.

I agree with your observation that it would be unsafe to accept such 
a group simply as a result of negotiation. What I want is the ability 
for a community to accept a given group, a priori, and be able to 
tell one another that the group they previously agreed to use is the 
one to use for a given SA.

>            from private use space and use that ine IKE.

The problem my clients have encountered is that vendors generally 
provide NO management interface to enter the parameters for private 
groups. Thus the existence of this facility has, in effect, been 
useless.  However, if we mandated in IKEv2 that a management 
interface MUST be present to configure private groups, which can then 
be referenced as you note above, I think that would suffice.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 25 Jun 2003 16:14:35 +0300

> one to use for a given SA.

This can be archieved by the private number space groups. Also note
that the current draft do say:
----------------------------------------------------------------------
3.3.4 Mandatory Transform IDs
...
   It is likely that IANA will add additional transforms in the future,
   and some users may want to use private suites, especially for IKE
   where implementations should be capable of supporting different
   parameters, up to certain size limits. In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman parameters (the generator, modulus, and exponent lengths and
   values) for new DH groups. Implementations SHOULD provide a
   management interface via which these parameters and the associated
   transform IDs may be entered (by a user or system administrator), to
   enable negotiating such groups.
...
----------------------------------------------------------------------

I.e implementations SHOULD have capability to input those private
groups to the system. 

> groups. Thus the existence of this facility has, in effect, been 

I think most of them do not provide the management interface, because
the do not provide any way to use private groups at all. Now this
management interface is "SHOULD", so hopefully more people will
implement it. It is also much easier to implement only the adding of
new groups without the capability of sending the group parameters in
the wire, so hopefully more implementations will follow this "SHOULD". 

> be referenced as you note above, I think that would suffice.

I am fine with MUST too, but I think SHOULD is enough. For some very
small boxes they might want to limit to the only one group or
something, and they might not have any configuration interface at
all... 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: jeff pickering <[email-masked]>
Date: Wed, 25 Jun 2003 15:23:48 -0400

We have mandated no management interface for any other feature so it would
seem extremely inconsistent to me to do this here.

Stephen Kent wrote:

> I agree with your observation that it would be unsafe to accept such a 
> group simply as a result of negotiation. What I want is the ability 
> for a community to accept a given group, a priori, and be able to tell 
> one another that the group they previously agreed to use is the one to 
> use for a given SA.
>
> useless.  However, if we mandated in IKEv2 that a management interface 
> MUST be present to configure private groups, which can then be 
> referenced as you note above, I think that would suffice.
>
> Steve
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 19:00:37 -0400

>seem extremely inconsistent to me to do this here.

Jeff,

I'm not sure what scope you had in mind when you made this comment.

RFC 2401 mandates lots of management features for IPsec 
implementations, in terms of the ability to configure SPD entries. In 
that light, mandating support for a management capability to specify 
private group parameters is completely consistent with what we have 
done previously, in the larger IPsec context.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 19:09:57 -0400

>that the current draft do say:

Thanks for the explanation. I agree that we have what we need here 
already, and I apologize for not reading closely enough.

Or, as they used to say on SNL "NEVERMIND."

Steve