[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] Proposed Last Call based revisions to IKEv2
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
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec