Subject: [Ipsec] Proposed Last Call based revisions to IKEv2

From: "Charlie Kaufman" <[email-masked]>
Date: Sat, 15 May 2004 22:50:15 -0700

Based on the discussion on the list, I believe these are the final edits
to IKEv2. If anyone disagrees, please speak up before I send out -14.

	--Charlie

(Diffs to source with typos and version # changes omitted):
Issue #99
========================================================================
===
***************************************************** i040322.txt, Line
349
 !         !                 IPsec                    !         !
 !Protected!                 Tunnel                   !Protected!
***************************************************** i040509.txt, Line
349
 !         !                 IPsec Transport          !         !
 !Protected!                or Tunnel Mode SA         !Protected!
========================================================================
===
***************************************************** i040322.txt, Line
359
IPsec. These endpoints may implement application layer access
controls based on the authenticated identities of the
participants. Transport mode will commonly be used with no
inner IP header. If there is an inner IP header, the inner addresses
will be the same as the outer addresses. A single pair of addresses
will be negotiated for packets to be protected by this SA.
***************************************************** i040509.txt, Line
359
IPsec, as required of hosts in [RFC2401bis]. Transport mode will
commonly be used with no inner IP header.
If there is an inner IP header, the inner addresses
will be the same as the outer addresses. A single pair of addresses
will be negotiated for packets to be protected by this SA. These
endpoints MAY implement application layer access controls based on the
IPsec authenticated identities of the participants. This scenario
enables the end-to-end security that has been a guiding principle for
the Internet since [RFC1958], [RFC2775], and a method of limiting
the inherent problems with complexity in networks noted by [RFC3439].
While this scenario may not be fully applicable to the IPv4 Internet,
it has been deployed successfully in specific scenarios within intranets
using IKEv1. It should be more broadly enabled during the transition
to IPv6 and with the adoption of IKEv2.

Completion of change to AUTH calculation recommended by Hugo and CFRG
========================================================================
===
**************************************************** i040322.txt, Line
1581
SK_pi and SK_pr which are only used when authenticating with an
EAP authentication mechanism that does not generate a shared key.
**************************************************** i040509.txt, Line
1589
SK_pi and SK_pr which are used when generating an AUTH
payload.
========================================================================
===
**************************************************** i040322.txt, Line
1628
prf(SK_ar,IDr') where IDr' is the responder's ID payload excluding the
fixed header. Note that neither the nonce Ni nor the value
prf(SK_ar,IDr')
are transmitted.  Similarly, the initiator
signs the first message, starting with the first octet of the first
SPI in the header and ending with the last octet of the last payload.
Appended to this (for purposes of computing the signature) are the
responder's nonce Nr, and the value prf(SK_ai,IDi'). In the above
calculation,
**************************************************** i040509.txt, Line
1636
prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding the
fixed header. Note that neither the nonce Ni nor the value
prf(SK_pr,IDr')
are transmitted.  Similarly, the initiator
signs the first message, starting with the first octet of the first
SPI in the header and ending with the last octet of the last payload.
Appended to this (for purposes of computing the signature) are the
responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above
calculation,

Wording error reported by Mohan Parthasarathy
========================================================================
===
**************************************************** i040322.txt, Line
2117
some older NATs modify IKE traffic on port 500 in an attempt to
transparently
establish IPsec connections. Such NATs may interfere with the
**************************************************** i040509.txt, Line
2125
some older NATs handle IKE traffic on port 500 cleverly
in an attempt to transparently
establish IPsec connections between endpoints that don't handle
NAT traversal themselves. Such NATs may interfere with the

Issue #103
========================================================================
===
**************************************************** i040322.txt, Line
2808
AUTH_AES_XCBC_96           5
**************************************************** i040509.txt, Line
2818
AUTH_AES_PRF_128           5                     (RFC3664)

Proposal from Ted Ts'o 4/6/04
========================================================================
===
**************************************************** i040322.txt, Line
3199
An opaque octet stream which may be used to pass an account
name or
**************************************************** i040509.txt, Line
3209
An opaque octet stream which may be used

Issue #94
========================================================================
===
**************************************************** i040322.txt, Line
3328
          id-mod-cert-bundle(TBD) }
**************************************************** i040509.txt, Line
3337
          id-mod-cert-bundle(34) }

Issue #96, 98
========================================================================
===
**************************************************** i040322.txt, Line
3930
RESERVED TO IANA - STATUS TYPES      16395 - 40959
**************************************************** i040509.txt, Line
3960
NON_FIRST_FRAGMENTS_ALSO                 16395
.sp
.in 12
This notification occurs may occur in the request and response of a
CREATE_CHILD_SA exchange. It indicates that its sender would like to
send
and is willing to receive non-initial IP fragments on the SA being
established
if the corresponding initial IP fragment was sent on the SA even if the
SA does not negotiation the sending of OPAQUE packets. This notification
MUST NOT be send in a response unless it was present in the
corresponding
request and both ends MUST NOT send such fragments unless this
notification
was present in both the request and the response.
.in 8
RESERVED TO IANA - STATUS TYPES      16396 - 40959
========================================================================
===
**************************************************** i040322.txt, Line
4144
   which port is undefined, or if all ports are allowed or
   port is OPAQUE, this field MUST be zero. For the
   ICMP protocol, the two one octet fields Type and Code are
   treated as a single 16 bit integer (with Type in the most
   significant eight bits and Code in the least significant
   eight bits) port number for the purposes of filtering based
   on this field.
.sp
o  End Port (2 octets) - Value specifying the largest port
   number allowed by this Traffic Selector. For protocols for
   which port is undefined, or if all ports are allowed or
   port is OPAQUE, this field MUST be 65535. For the
   ICMP protocol, the two one octet fields Type and Code are
   treated as a single 16 bit integer (with Type in the most
   significant eight bits and Code in the least significant
   eight bits) port number for the purposed of filtering based
   on this field.
**************************************************** i040509.txt, Line
4186
   which port is undefined, or if all ports and packets where
   port is OPAQUE are allowed, this field MUST be zero. For
   the ICMP protocol, the two one octet fields Type and Code
   are treated as a single 16 bit integer (with Type in the
   most significant eight bits and Code in the least
   significant eight bits) port number for the purposes of
   filtering based on this field. A Start Port value of 65535
   with an End Port value of 0 in a traffic selector indicates
   non-initial IP fragments where the port is therefore OPAQUE.
   Any other Traffic Selector where Start Port > End Port is
   invalid, MUST NOT be sent, and MUST be ignored on receipt.
.sp
o  End Port (2 octets) - Value specifying the largest port
   number allowed by this Traffic Selector. For protocols for
   which port is undefined, or if all ports and packets where
   port is OPAQUE are allowed, this field MUST be 65535. For the
   ICMP protocol, the two one octet fields Type and Code are
   treated as a single 16 bit integer (with Type in the most
   significant eight bits and Code in the least significant
   eight bits) port number for the purposed of filtering based
   on this field. A Start Port value of 65535 with an End Port
   value of 0 in a traffic selector indicates non-initial IP
   fragments where the port is therefore OPAQUE. Any other
   Traffic Selector where Start Port > End Port is invalid,
   MUST NOT be sent, and MUST be ignored on receipt.

Issue #97
========================================================================
===
**************************************************** i040322.txt, Line
4740
sufficient for use with 3DES.  Groups three through five provide greater
security. Group one is for historic purposes only and does not provide
sufficient strength except
for use with DES, which is also for historic use only. Implementations
should make note of these conservative estimates when establishing
**************************************************** i040509.txt, Line
4806
common for use with 3DES.  Group five provides greater
security than group two.
Group one is for historic purposes only and does not provide
sufficient strength except
for use with DES, which is also for historic use only. Implementations
should make note of these estimates when establishing

Issue #100
========================================================================
===
**************************************************** i040322.txt, Line
3426
a chain of certificates. If a certificate exists which satisfies the
criteria specified in the Certificate Request Payload, the certificate
MUST be
sent back to the certificate requestor; if a certificate chain exists
which goes back to the certification authority specified in the request
the entire chain SHOULD be sent back to the certificate requestor. If
multiple
certificates or chains exist that satisfy the request, the sender MUST
pick
one. If
no certificates exist then the Certificate Request Payload is ignored.
This
is not an error condition of the protocol. There may be cases where
there is a preferred CA, but an alternate might be acceptable (perhaps
after prompting a human operator).
**************************************************** i040509.txt, Line
3435
a chain of certificates.

If an end-entity certificate exists which satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if:
.sp
 - the recipient of the CERTREQ is configured to use certificate
authentication,
.sp
 - is allowed to send a CERT payload,
.sp
 - has matching CA trust policy governing the current
negotiation, and
.sp
 - has at least one time-wise and usage appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.
.sp
Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic. The
intent is not to prevent communication through the strict adherence
of selection of a certificate based on CERTREQ, when an alternate
certificate could be selected by the sender which would still enable
the recipient to successfully validate and trust it through trust
conveyed by cross-certification, CRLs or other out-of-band configured
means. Thus the processing of a CERTREQ CA name should be seen as a
suggestion for a certificate to select, not a mandated one. If no
certificates exist then the CERTREQ is ignored. This is not an error
condition of the protocol. There may be cases where there is a
preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator)."
========================================================================
===
**************************************************** i040322.txt, Line
4727
**************************************************** i040509.txt, Line
4777
While this protocol is designed to minimize disclosure of configuration
information to unauthenticated peers, some such disclosure is
unavoidable.
One peer or the other must identify itself first and prove its identity
first.
To avoid probing, the initiator of an exchange is required to identify
itself first, and usually is required to authenticate itself first. The
initiator can, however, learn that the responder supports IKE and what
cryptographic protocols it supports. The responder (or someone
impersonating
the responder) can probe the initiator not only for its identity, but
using
CERTREQ payloads may be able to determine what certificates the
initiator
is willing to use.
.sp
Use of EAP authentication changes the probing possibilities somewhat.
When
EAP authentication is used, the responder proves its identity before the
initiator does, so an initiator that knew the name of a valid initiator
could
probe the responder for both its name and certificates.
.sp
========================================================================
===
**************************************************** i040322.txt, Line
5010
**************************************************** i040509.txt, Line
5077

   [RFC1958]  Carpenter, B., "Architectural Principles of the
              Internet", RFC 1958, June 1996.
========================================================================
===
**************************************************** i040322.txt, Line
5030
   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, October 2000.
**************************************************** i040509.txt, Line
5100
   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              February 2000.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels",
              RFC 2983, October 2000.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3429, December 2002.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 17 May 2004 10:36:21 -0700

>Issue #96, 98

Charlie has proposed changes to align with the fragmentation 
description in rfc2401bis. I have a different proposition, one that I 
think the WG may like even better than the one Charlie gave while 
still achieving the same goal of giving rfc2401bis what it needs.

One of the huge problems with IKEv1/2401 is that the specification 
for how to do things is spread among multiple RFCs. We have cleaned 
that up to a huge extent in IKEv2/2401bis. However, what Charlie 
suggests here creates the split again; I think we can nip that in the 
bud.

What I propose is that Charlie only change the following in IKEv2:

- In 3.10, add an entry under status-type notify messages:

    NON-FIRST-FRAGMENTS-ALSO                  16395

    Used for fragmentation control. See [RFC2401bis] for explanation.

- In 3.13.1, eliminate "or port is OPAQUE" in both Start Port and End 
Port descriptions.

- In 3.13.1, just before the text paragraph that starts "The 
following table lists...", add the following paragraph.

    Systems that are complying with [RFC2401bis] that wish to indicate
    "ANY" ports MUST set the start port to 0 and the end port to 65535;
    note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems
    working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but
    not "ANY" ports, MUST set the start port to 65535 and the end port
    to 0.

This way, the IKEv2 document is not specifying any semantics for 
fragmentation handling, and there is no possibility of disagreement 
with 2401bis. It also separates out the semantics of OPAQUE and ANY 
in a way to make it clear that these are 2401bis constructs, not 
IKEv2 constructs.

One concern with using Charlie's text is that it would likely cause 
the need for another WG Last Call and another IETF Last Call. I 
believe the above changes could avoid that because the revisions do 
not specify any new semantics. (Russ, does that sound correct to you?)

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 17 May 2004 10:36:21 -0700

--Paul Hoffman, Director
--VPN Consortium