[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



William:

I encourage you to work on the proposed document. However, I do not want to delay IKEv2 while it it written. There are other cases in the IETF where similar documents have been written after the base document. RFC 3218 is one example.

Russ

At 08:57 PM 5/23/2004, William Dixon wrote:
Charlie, I note that the current comments on the discoverability of
information through passive monitoring and through active probing is not
complete. I'd prefer that we err on the side of explicitly explaining the
risks of the protocol design where certain types of use of protocol features
would be risky.

Regarding:
"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."

Comments:

Deployment situations require a responder to advertise aspects of itself or
to keep aspects of itself private. I made a comment at an IETF 2 or 3 years
ago that I wish that the protocol accommodated the ability for a responder
to authenticate first when operating in "public mode", but that is water
under the IKEv2 bridge I guess. I also spoke in support of a requirements
document could have specified what scenarios IKEv2 was suited for. Certainly
none now that require a server to authenticate before a client...

To the text quoted above, the optional CERTREQ from the responder reveals
the trust anchors that the unauthenticated responder would presumably use to
authenticate the initiator. Certain usages of the CERTREQ payload (by
default for example) in products may inadvertently increase the risk to the
customer. The risk is when the CERTREQ contains a DN of a CA name that
identifies the organizational owner of the gateway, and certainly which
trust infrastructure must be compromised. This could provide important
information to the attacker if the CA name were the lowest level of issuing
authority for which a certificate was accepted (such as "Defense Nuclear
Analysis Branch Issuing CA"), or perhaps generally useful but less specific
information if the CA DN name were the root CA name (such as "Defense Dept
Root CA"). The use of PKI technology and certain privately owned PKIs for
IKEv2 may not in fact be something that is intended to be known or
advertised publicly. Thus it may be necessary to rely solely upon initiator
configuration or user selection to know which certificate to offer.

To avoid the IKEv2 draft becoming a dissertation on how to probe and attack
IKE, I think a new draft detailing this should be submitted. In fact, I
think such a draft should be required of a security protocol so that
developers have a very clear understanding of how their product
implementation can be attacked or used for surveillance or to gather
pre-attack information. Clearly those building such tools will know it.

So my change text for -14 is:

"The initiator of an IKEv2 negotiation can discover information about a
responder. While IKEv2 is designed such that the initiator can not discover
the full identity of the responder, the support of certain features of the
protocol in implementations as well as their particular use in deployment
may provide useful information for adversaries.[IKEv2ATTACK]"

[IKEv2ATTACK] TBD.

If the WG would like to advance such a draft, I can offer an initial one in
approximately mid to late July.

Wm


> -----Original Message----- > From: ipsec-admin@xxxxxxxx [mailto:ipsec-admin@xxxxxxxx] On > Behalf Of Charlie Kaufman > Sent: Sunday, May 16, 2004 1:50 AM > To: ipsec@xxxxxxxx > Subject: [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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ipsec > >


_______________________________________________ Ipsec mailing list Ipsec@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ipsec


_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec