Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 25 Feb 2003 14:45:31 -0500

Charlie Kaufman has released the next version of IKEv2
(draft-ietf-ipsec-ikev2-05.txt) and we are slowly but surely getting
closer to completion.  Many thanks to Charlie and those who
contributed text, ideas, and bug fixes to this new version of the
ikev2 I-D.

At the time when Charlie began his revisions to produce the 05 I-D,
there were still a few open issues.  In the meantime, some additional
issues have opened up, including the discussion between Tero, Francis,
and Radia regarding address management and whether IKE v2 adequately
handles NAT traversal (particularly in transport mode).  Furthermore,
ikev2-05 has changed significantly and has much new material to
address various concerns addressed by those on the list, including the
addition of the agreed-upon handling of legacy authentication, more
explicit specifications about when the CERT and CERTREQ packets much
be sent and how they should be handled, the addition of crypto suites,
and so on.

Because of the large amount of changes, and a few remaining open
issues, it is clear that it would be premature to issue a last call on
the ikev2-05 document.  However, in order to continue to make forward
progress, what Barbara and I would like to do is to issue a last call
on open issues and specific proposals for edits to the ikev2
specification.

Specifically, in the next two weeks, we request all members of the IPSEC
working group to carefully read and digest the ikev2 specification, and
make known any issues they may have with the document, complete with
specific changes to the document which they believe would resolve those
issues.  

For example, in the case of the open issue on how to handle
configuration, the choices to the working group are:

	* Keep configuration payload
	* Remove configuration payload and pursue RFC 3456-style configuration
	* Keep configuration payload and allow optional 
		RFC 3456-style configuration

Depending on how the working group decides this issue in San
Francisco, the net effect on the IKE v2 document will ultimately be
whether or not section 3.15 (Configuration payload) is removed, and
whether or not either the ipsec or ipsra working group shall pursue an
update to RFC 3456 to support IKEv2.

So we hereby issue a "last call" for open issues regarding the ikev2
I-D that need to be addressed by this working group.  This last call
will terminate in two weeks, at the commencement of the San Francisco
IETF meeting.  During this last call period, we will be collecting and
summarizing open issues which are brought up, with the goal of
resolving all of these issues either before or at the IPSEC working
group meeting in San Francisco.  After this "issues last call" is
completed, the working group will not entertain any additional new
issues unless they represent a fundamental flaw to the IKEv2 protocol,
and we will be issuing final editing directions to the ikev2 document
editor so that we can finish this specification as soon as possible
after the San Francisco meeting.

					- Ted and Barbara

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 26 Feb 2003 11:27:51 +0200

Seems that only a week ago there was a wide-spread agreement on using the
configuration payload as it is in -05, with the client later completing any
missing data using tunneled DHCP informs.  This would mean that the security
gateway would not have to know the DHCP protocol.

Both RFC 3456 and the dhcp-over-ike drafts make sense only if IP addresses
are allocated by a DHCP server.  Of the two, I prefer the dhcp-over-ike
draft, but I still see some drawbacks:

- If the gateway has an internal pool or if it obtains the addresses from a
RADIUS server, it will have to translate the requests and replies from and
to DHCP format.  DHCP format is not simple and contains many irrelevant
fields.  Even if allocation is done using a DHCP server, the gateway will
need to learn to be a DHCP relay agent.  The configuration payload is much
simpler.

- DHCP packets are large (over 300 bytes) and unbounded in size.  The IKE
packets are already large enough to cause trouble occasionally.  We don't
need this extra baggage.  Configuration payloads are small by comparison.

- DHCP tunneling in IKE requires at least 4 packets, 6 if the client makes
an attempt to obtain a previous address.  This will make the IKE negotiation
go to 6 or 8 packets as opposed to 4 in -05.

I am in favor of the first option: use CP to pass IP address, subnet mask
and DHCP server address (optionally also NBNS, DNS) and optionally use DHCP
inform for all the rest.

Yoav Nir

  -----Original Message-----
  Subject: OPEN ISSUES WG LAST CALL: draft-ietf-ipsec-ikev2-05.txt
  <snip>

=========================================================================
The content of this message may contain private views and opinions which do
not constitute a formal disclosure or commitment.

---

From: Pekka Riikonen <[email-masked]>
Date: Wed, 26 Feb 2003 12:33:32 +0100 (CET)

: explicit specifications about when the CERT and CERTREQ packets much
: be sent and how they should be handled, the addition of crypto suites,
:
I would still raise the issue of CR payload usage I mentioned a while
back.  The ability for initiator to request 'any' cert from responder
(regardless of the CA) would be in my opinion important to have.  The way
specs seems to suggest implementation to work is that CERT is not sent if
CERTREQ is not sent, if CERTREQ was sent but no such CA was found CERT is
still not sent.  This means that you must know the CA before hand or you
must have the cert cached for the exchange to ever succeed (since you
won't have the public key to verify the AUTH).  Now, maybe in ideal world
everyone always know who everyone else trusts or everybody trusts always
the same CAs but I think in real world this won't be the case.

The way in IKEv1 this was done was to unofficially agree between vendors
(eg. in every bakeoff for past several years I've attended to) that empty
CR payload means kind of "any" request.  IKEv2 does not allow this, but
pki-profile provides a loophole for it anyway.  What I am suggesting is
that empty CR payloads would be allowed in IKEv2 (explicitly), or by some
other mechanism (eg. ANY cert encoding (but I don't like this very much)).

The second issue that would be nice to consider and decide is the
expansion of usage of CERTREQ to allow the verification of whether a
cached cert is the correct or not by including eg. the hash of the cert in
CERTREQ.  This also relates to the earlier revised identity discussion on
the list.

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: [email-masked]
 SSH Communications Security Corp. | http://iki.fi/priikone/
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc