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: "William Dixon" <[email-masked]>
Date: Sun, 23 May 2004 20:57:16 -0400

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charlie Kaufman
> Sent: Sunday, May 16, 2004 1:50 AM
> To: [email-masked]
> 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
> 
> 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.
> 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 
> 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.
> 
> 
> 
> SK_pi and SK_pr which are only used when authenticating with 
> an EAP authentication mechanism that does not generate a shared key.
> SK_pi and SK_pr which are used when generating an AUTH payload.
> 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,
> 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,
> 
> 
> 
> some older NATs modify IKE traffic on port 500 in an attempt 
> to transparently establish IPsec connections. Such NATs may 
> interfere with the
> 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
> An opaque octet stream which may be used to pass an account name or
> **************************************************** 
> i040322.txt, Line 3930
> **************************************************** 
> i040509.txt, Line 3960
> 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
> **************************************************** 
> 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
> 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
> 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).
> 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
> negotiation, and .sp
>  - has at least one time-wise and usage appropriate 
> end-entity certificate chaining to a CA provided in the CERTREQ.
> .sp
> 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)."
> 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
> 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
> **************************************************** 
> i040322.txt, Line 5030
> **************************************************** 
> i040509.txt, Line 5100

---

From: "William Dixon" <[email-masked]>
Date: Sun, 23 May 2004 20:57:16 -0400

Regarding:

Comments:

[IKEv2ATTACK] TBD.

Wm

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 23 May 2004 21:49:29 -0600

The risks that William Dixon mentions wrt to the exposure of sensitive
information in certificates or certificate requests can be eliminated
through the use of "Hidden Credentials".  The HC method
allows both sides (authenticatee and authenticator) in the
authentication exchange to keep their requirements and credentials
secret unless there is a match that will allow authentication to
succeed.

I presented this at an IPSec meeting a few IETF's ago.  The only known
implementation relies on Identity-Based Encryption (IBE) which is
patented IPR, and IBE relies on elliptic curve groups, which have some
associated IPR.  Despite these drawbacks, Hidden Credentials do solve
an important trust problem for protocols like IKE, and might be worth
some thought for IKEng.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Sun, 23 May 2004 21:49:29 -0600

Hilarie

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 11:59:20 +0300

> configuration or user selection to know which certificate to offer.

NOte, that in IKEv2 the DN of the CA is NOT sent. The Certificate
request payload contains SHA-1 hashes of the public keys of trusted
CAs. So when the attacker see that the initiator trust CA
"94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" (in binary), it is little
hard to know which CA it actually trusts unless you already know the
CA public key. So without seeing the actual certificate you cannot
know which CA it trust. You can however still track that this client
uses the same CA than that other client....

If we would want to hide that information too, we would be required to
add IKE-SPIs to the hash, i.e defiene that the SHA-1 hashes CERTREQ
are HMAC keyed hash using the IKE-SPI of the hash of the public key,
or similar (i.e. CERTREQ_PAYLOAD = HMAC(IKE_SA initoator SPI, SAH-1
hash of the public key of CA). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 11:59:20 +0300

---

From: "William Dixon" <[email-masked]>
Date: Mon, 24 May 2004 09:36:59 -0400

Wow, I forgot to re-check that. Sorry. The hashes are a significant
improvement. Any thoughts on whether we should pursue the IKEv2 attack draft
I suggested ? I see it as a full treatment of security considerations.

> Behalf Of Tero Kivinen
> Sent: Monday, May 24, 2004 4:59 AM
> To: William Dixon
> Cc: 'Charlie Kaufman'; [email-masked]
> Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2
> 
> William Dixon writes:
> > 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
> > advertised publicly. Thus it may be necessary to rely solely upon 
> > initiator configuration or user selection to know which 
> certificate to offer.
> 
> NOte, that in IKEv2 the DN of the CA is NOT sent. The 
> Certificate request payload contains SHA-1 hashes of the 
> public keys of trusted CAs. So when the attacker see that the 
> initiator trust CA "94ea1e00fb5e85fea5e645aab20fb408dce3c4b1" 
> (in binary), it is little hard to know which CA it actually 
> trusts unless you already know the CA public key. So without 
> seeing the actual certificate you cannot know which CA it 
> trust. You can however still track that this client uses the 
> same CA than that other client....
> 
> 
> If we would want to hide that information too, we would be 
> required to add IKE-SPIs to the hash, i.e defiene that the 
> SHA-1 hashes CERTREQ are HMAC keyed hash using the IKE-SPI of 
> the hash of the public key, or similar (i.e. CERTREQ_PAYLOAD 
> = HMAC(IKE_SA initoator SPI, SAH-1 hash of the public key of CA). 
> --
> [email-masked]
>

---

From: "William Dixon" <[email-masked]>
Date: Mon, 24 May 2004 09:36:59 -0400

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 May 2004 09:57:27 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 May 2004 09:57:27 -0400

William:

Russ

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 25 May 2004 16:14:12 -0400

> to IKEv2. If anyone disagrees, please speak up before I send out -14.

Charlie, 

It's been a week and we received two suggestions.  One was Paul's very
good suggestion keep the changes regarding fragmentation handling in
RFC-2401bis, which has the advantage of avoiding another IETF-wide
last call on your document.  The other was William Dixon's suggestion
for providing better advanced handling support, which as Russ has
pointed out can be done independently without blocking the progress of
the IKEv2 draft.  Barbara and I believe you should accept Paul's
suggestion, and not make any changes to IKEv2 in response to points
raised by William Dixon on this thread.  If he would like to do that
work as a separate draft, in another working group, it appears that
the Area Directors will be receptive to such an approach.

If you could get -14 published at your earlier convenience, we will
then inform Russ that all of the comments raised during the IETF last
call process have been resolved, and he should proceed with the
getting IESG approval for publishing IKEv2 as a standards-track RFC.

Many thanks for all of your very hard work,

					- Ted and Barbara

---

From: "William Dixon" <[email-masked]>
Date: Tue, 25 May 2004 18:15:35 -0400

Fine with me. I wasn't trying to delay the IKEv2 document, thus I suggested
another one. I'll post a follow-up to assess the interest in an attack draft
when I'm able to start work on it.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Theodore Ts'o
> Sent: Tuesday, May 25, 2004 4:14 PM
> To: Charlie Kaufman
> Cc: [email-masked]
> Subject: Re: [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, 
> 
> It's been a week and we received two suggestions.  One was 
> Paul's very good suggestion keep the changes regarding 
> fragmentation handling in RFC-2401bis, which has the 
> advantage of avoiding another IETF-wide last call on your 
> document.  The other was William Dixon's suggestion for 
> providing better advanced handling support, which as Russ has 
> pointed out can be done independently without blocking the 
> progress of the IKEv2 draft.  Barbara and I believe you 
> should accept Paul's suggestion, and not make any changes to 
> IKEv2 in response to points raised by William Dixon on this 
> thread.  If he would like to do that work as a separate 
> draft, in another working group, it appears that the Area 
> Directors will be receptive to such an approach.
> 
> If you could get -14 published at your earlier convenience, 
> we will then inform Russ that all of the comments raised 
> during the IETF last call process have been resolved, and he 
> should proceed with the getting IESG approval for publishing 
> IKEv2 as a standards-track RFC.
>