Subject: [IPsec] Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Jan 2010 18:02:21 +0200

Here is the final part of my comments. 

----------------------------------------------------------------------
In section 2.23.1 there is extra "the":

				 It can have multiple traffic
   selectors if it has, for example, multiple port ranges that it wants
   to negotiate, but all TSi entries must use IP1-IP1 range as the IP
   addresses, and all TSr entries must have the IPN2-IPN2 range as IP
   the addresses.  The first traffic selector of TSi and TSr SHOULD have
   ^^^
     \-- There

Also there is extra "as" in this sentence:

   In this case, the server should first check that as initiator
						    ^^
   requested transport mode and do address substitution on the traffic
   selectors.  

There is also typo:

      (thta is, it replaces IPN2 in TSr with IP2).
       ^^^^

Also the bullet

   - Store the original traffic selector IP addresses as real source
     and destination address in case we need to undo address
     substitution.

needs to be changed to

   - Store the original traffic selector IP addresses as real source
     and destination address and also in case we need them to undo
     address substitution.

The whole section 2.23.1 would require someone to do some langauge
cleanup for it.

----------------------------------------------------------------------

In section 2.25 the CHILD_SA_NOT_FOUND text could be bit expanded to
explain bit more, i.e. change:

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist.  A peer that
   receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
   Child SA and send a request to create a new Child SA from scratch.

to

   A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
   a request to rekey a Child SA that does not exist A peer that receives
   a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA
   (if it still exists, as most likely delete notification sent by the
   other hand has already deleted it) and send a request to create a new
   Child SA from scratch if such Child SA does not yet exists.

----------------------------------------------------------------------

In section 3.3.6 there is few odd sentences at the end of second
paragraph:

					An exception is
   the case where one of the proposals offered is for the Diffie-Hellman
   group of NONE.  In this case, the responder MUST ignore the
   initiator's KE payload and omit the KE payload from the response.

Before this it talked about the extensibility and so, and I do not
understand how the Diffie-Hellman negotiation is an exception of that
case.

The next paragraph talks about the Diffie-Hellman negotiation, and I
think this text belongs to there, not in this paragraph, altough the text
needs to be modified when moved to there to match the context.

----------------------------------------------------------------------

In section 3.6 we have text which says:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  

which is bit misleading, as even if HTTP_CERT_LOOKUP_SUPPORTED notify
payload is sent that does not mean peer should leave out all Certificate
payloads, it just means it should use Hash and URL formats instead of
sending full certificates.

Perhaps it should be changed to:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender. The Hash and URL formats of
   the Certificate payloads should be used in case the peer has indicated
   an ability to retrieve this information from elsewhere using an
   HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

----------------------------------------------------------------------

Section "3.10.1.  Notify Message Types" should include:

   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

   CHILD_SA_NOT_FOUND		 {TBA2}
       See section 2.25.

It is funny that section "E.13. Changes from
draft-ietf-ipsecme-ikev2bis-05 to draft-ietf-ipsecme-ikev2bis-06" claims
that text was added to there, but it isn't there.

Also in the beginning of error code list it would be better to put
pointer to the section "2.21 Error Handling" is it covers text for more
than one of those errors notifications. Also following references could
also be added:

   INVALID_KE_PAYLOAD                       17
       See Section 1.3.

also section 2.7

   AUTHENTICATION_FAILED                    24
       Sent in the response to an IKE_AUTH message when for some reason
       the authentication failed. There is no associated data.

Section 2.21.2.

----------------------------------------------------------------------

In section "3.15.1.  Configuration Attributes" the text before the table
saying:

      The values in the following table are only current as of the
      publication date of RFC 4306.  Other values may have been added
      since then or will be added after the publication of this
      document.  Readers should refer to [IKEV2IANA] for the latest
      values.

Is not true, as the RFC4306 included INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed from the table. Perhaps text should
be changed to:

      The values in the following table are only current as of the
      publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
      INTERNAL_IP6_NBNS which were removed by this document). Other
      values may have been added since then or will be added after the
      publication of this document. Readers should refer to [IKEV2IANA]
      for the latest values.

The INTERNAL_ADDRESS_EXPIRY removal was listed in the section 1.7 but
INTERNAL_IP6_NBNS wasn't. I am not sure if that is big enough sure to
require note in the section 1.7. 

----------------------------------------------------------------------

In section 6. IANA Considerations it is missing the removal of
INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY attribute types from the
IKEv2 Configuration Payload Attribute Types table.

----------------------------------------------------------------------

In section C.5 it shows KEi and KEr as optional payloads, but they are
not optional for IKE SA rekey, i.e. the exchange should be:

C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE SA

   request             --> SA, Ni, KEi
                           [V+][N+]

   response            <-- SA, Nr, KEr
                           [V+][N+]

----------------------------------------------------------------------

In section 2.16 we say:

						For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public key signature based authentication of the responder to the
   initiator.

but in the section 5 we say:

   An implementation using EAP MUST also use strong authentication of
   the server to the client before the EAP authentication begins, even
   if the EAP method offers mutual authentication.

In the appendix E we can se that we first changed both section 2.16 and
section 5 to say "strong authentication", but then we changed the section
2.16 back from "strong authentication" to "public key signature based
authentication", but we didn't change the section 5 back to its original
way.

Should we make them consistent and convert the section 5 back to its
original form? 

----------------------------------------------------------------------
Following things might or might not need to be added to section 1.7
(taken from appendix E):

   In the description of ID_FQDN in Section 3.5, added "All characters
   in the ID_FQDN are ASCII; this follows that for an "internationalized
   domain name" as defined in [IDNA]."
...
   In Section 3.3.2, changed the following algorithms to (UNSPECIFIED)
   because the RFCs listed didn't really specify how to implement them
   in an interoperable fashion:

   Encryption Algorithms
   ENCR_DES_IV64        1           (RFC1827)
   ENCR_3IDEA           8           (RFC2451)
   ENCR_DES_IV32        9
   Pseudo-random Functions
   PRF_HMAC_TIGER              3         (RFC2104)
   Integrity Algorithms
   AUTH_DES_MAC         3
   AUTH_KPDK_MD5        4        (RFC1826)
...
   Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2.
   [Issue #33]
...
   Changed the "Initialization Vector" bullet in Section 3.14 to specify
   better what is needed for the IV.  Upgraded the SHOULDs to MUSTs.
   Also added the reference for [MODES].
...
   In section 2.6, upgraded "needs to choose them so as to be unique
   identifiers of an IKE_SA" to a MUST.
...
   Added a reference to email address internationalization to 3.5,
   making the address binary (not ASCII).
...
   In 3.14, updated the discussion of initialization modes to reflect
   that it is only about CBC, and that other specs have to specify their
   own IVs.
...
   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
   "The KEi payload MUST be included".  This also lead to changes in
   section 2.18.  The square brackets around "g^ir (new)" in the
   SKEYSEED calculation are eliminated, and the requirement language in
   the paragraph starting "The main rekeying" is changed from SHOULD to
   MUST.  [Issue #50]
...
   In 2.1, at the end of the paragraph about retransmission timers,
   added "In order to allow saving memory, responders are allowed to
   forget response after a timeout of several minutes.  If the responder
   receives a retransmitted request for which it has already forgotten
   the response, it MUST ignore the request (and not, for example,
   attempt constructing a new response)."  [Issue #14]
...
   Added the following to 2.23: An initiator can float to port 4500,
   regardless whether or not there is NAT, even at the beginning of IKE.
   When either side is using port 4500, sending with UDP encapsulation
   is not required, but understanding received packets with UDP
   encapsulation is required.  UDP encapsulation MUST NOT be done on
   port 500.  If NAT-T is supported (that is, if NAT_DETECTION_*_IP
   payloads were exchanged during IKE_SA_INIT), all devices MUST be able
   to receive and process both UDP encapsulated and non-UDP encapsulated
   packets at any time.  Either side can decide whether or not to use
   UDP encapsulation irrespective of the choice made by the other side.
   However, if a NAT is detected, both devices MUST send UDP
   encapsulated packets.  [Issue #40]
...
   In 2.5, changed "implementations MUST send the payloads defined in
   this specification in the order shown in the figures in Section 2;
   implementations are explicitly allowed to reject as invalid a message
   with those payloads in any other order" to "implementations SHOULD
   send the payloads defined in this specification in the order shown in
   the figures in Section 2; implementations MUST NOT reject as invalid
   a message with those payloads in any other order".  [Issue #16]
   [Issue #45]
...
   Removed INTERNAL_IP6_NBNS from 3.15.1.  [Issue #44]
...
   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
   different traffic selectors and algorithms than the old one." to
   "Note that, when rekeying, the new Child SA SHOULD NOT have different
   traffic selectors and algorithms than the old one.".  [Issue #12]
...
   Added 2.23.1, which covers how to handle NAT traversal when transport
   mode is requested.  [Issue #28]
...
   Added 2.25 and its subsections.  [Issue #22]
...
   Added to the end of 3.6: "Implementations MUST support the HTTP
   method for hash-and-URL lookup.  The behavior of other URL methods is
   not currently specified, and such methods SHOULD NOT be used in the
   absence of a document specifying them."  [Issue #117]
...
   In 3.7, removed "10" from the list of acceptable types for the
   "Certification Authority" field.  [Issue #120]
...
   In 3.10.1, added

   TEMPORARY_FAILURE
       See section 2.25.

   CHILD_SA_NOT_FOUND
       See section 2.25.
...

I tried to pick ones which might affect existing implementations (i.e.
where we changed something to MUST when it was SHOULD etc, or where we
expanded or added specifications to cases which were not specified
properly previously).

Some of those are already cases where there might be some text in 1.7 or
which have already been pointed out, but I added those still to this more
complete list just to make sure.

BTW what is going to be the relationship between section 1.7 and
Appendix D?
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Jan 2010 18:22:45 -0800

Another big thank you for doing this review. I have incorporated everything other than the following.

needs to be changed to

[[ Response: That wording doesn't make any sense to me. ]]

[[ Response: The proposed change does not make sense: it sounds like a peer SHOULD send *both* the certificates and the hash-and-URL, which is silly. ]]

   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

[[ Response: Can't do that: the WG decided we have to leave the tables with the values defined in RFC 4306. Those two are, of course, listed in the IANA considerations. ]]

[[ Response: I included only some of those. 1.7 is not meant to be exhaustive: it can't be. But I did add a bunch you had suggested that I had missed on my pass. ]]

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 19 Jan 2010 08:57:49 +0200

I agree with Tero, regardless of the discussion we had on where to put the tables etc., the document needs to be internally consistent. So we should add the new notify types that we're defining in *this* document to the notify types table. Luckily there aren't many.

Thanks,
	Yaron

   TEMPORARY_FAILURE		 {TBA1}
       See section 2.25.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Jan 2010 10:34:41 +0300

Hi,

I also agree with Tero and Yaron. It's better to have all defined
notifications listed in one table.
In this case the paragraph immediately preceeding the table must be changed
from:

   The values in the following table are only current as of the
   publication date of RFC 4306.  Other values may have been added since
   then or will be added after the publication of this document.
   Readers should refer to [IKEV2IANA] for the latest values.

to something like:

   The values in the following table are only current as of the
   publication date of this document.  Other values may have been added
   since then. Readers should refer to [IKEV2IANA] for the latest values.

By the way, section 6 (IANA Considerations) contains typo:

   [IKEV2] defined many field types and values.  IANA has already
   registered those types and values in [IKEV2IANA], so the are not
                                                                            
      ^^^^
   listed here again.

Regards,
Valery Smyslov.

> I agree with Tero, regardless of the discussion we had on where to put the
tables etc., the document needs to be internally consistent. So we should
add the new notify types that we're defining in *this* document to the
notify types table. Luckily there aren't many.
> [[ Response: Can't do that: the WG decided we have to leave the tables
with the values defined in RFC 4306. Those two are, of course, listed in the
IANA considerations. ]]
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Jan 2010 10:21:46 +0200

+1

Anybody who starts implementing IKEv2 in a few months using the new RFC should not have to care about the history, and which notify type was added at which point, except to know that some implementations in the field may not support these newer notifications.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Tuesday, January 19, 2010 9:35 AM
To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; [email-masked]
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)

Hi,

to something like:

                                                                            
      ^^^^
   listed here again.

Regards,
Valery Smyslov.

Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 19 Jan 2010 10:22:09 +0200

To clarify, I was only referring to the notifications defined in -bis. Not in any other documents.

-----Original Message-----
From: Valery Smyslov [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2010 9:35
To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; [email-masked]
Subject: Re: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-ipsecme-ikev2 (section 2.23.1 forward)

Hi,

to something like:

                                                                            
      ^^^^
   listed here again.

Regards,
Valery Smyslov.

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 12:24:03 +0100

I think the tables should list the values needed to implement *this* 
specification; in all cases except here, that's the same as "defined 
in RFC 4306", but not in this case.

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Yaron Sheffer
> Sent: 19 January, 2010 08:58
> To: Paul Hoffman; Tero Kivinen; [email-masked]
> Subject: [IPsec] Notify types, was: RE: Review of rest of draft-ietf-
> ipsecme-ikev2 (section 2.23.1 forward)
> 
> I agree with Tero, regardless of the discussion we had on where to put
> the tables etc., the document needs to be internally consistent. So we
> should add the new notify types that we're defining in *this* document
> to the notify types table. Luckily there aren't many.
> 
> Thanks,
> 	Yaron
> 
> with the values defined in RFC 4306. Those two are, of course, listed
> in the IANA considerations. ]]
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 14:00:24 +0200

> [[ Response: That wording doesn't make any sense to me. ]]

There is two reason why original traffic selector IP addresses are
stored: 1) to use as "real source and destination address" as
specified by RFC3948 for TCP/UDP checksum fixup; 2) when they are
needed to undo address substitution in case we need to fall back to
tunnel mode.

The original text only mentioned the second use, not first use, and my
change tried to include both...

Perhaps you can try to write some wording that makes sense...

BTW, the RFC3948 uses term "peer's real source and destination IP
addresses" (section 3.1.2, option 1). The RFC3947 uses therm "Original
Source and Destination Addresses" (section 5.2).
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 14:03:27 +0200

Paul Hoffman writes:
> [[ Response: The proposed change does not make sense: it sounds like
> a peer SHOULD send *both* the certificates and the hash-and-URL,
> which is silly. ]]

Peer uses certificate payloads to send both full X.509 certificates
and hash-and url "certificates", so yes, when peer uses hash-and-URL
format it is still sending "certificates" inside the certificate
payloads, even though the actual X.509 certificate is not there.

Would this be better:

	   Certificate payloads SHOULD be included in an exchange if
   certificates are available to the sender. The Hash and URL formats
   of the Certificate payloads should be used instead of full X.509
   certificates in case the peer has indicated an ability to retrieve
   this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED
   Notify payload.

(The section 3.6 already notices that term "certificate" is misleading
as not all data is certificates in this payload). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 14:07:06 +0200

Paul Hoffman writes:
> [[ Response: Can't do that: the WG decided we have to leave the
> tables with the values defined in RFC 4306. Those two are, of
> course, listed in the IANA considerations. ]] 

I do not think we agreed on that. We agreed that we do not add any
values defined on other documents (i.e. AES-GCM etc).

I do not think we agreed that we should not update the table to
include the numbers defined in THIS document.

I think it would be better to have the table in 3.10.1 to be complete
set of notify message types which are used by this document. It does
not need to include notify message types from other documents or new
extensions, but it should include everything which is defined in this
document. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Jan 2010 14:12:38 +0200

Paul Hoffman writes:
> [[ Response: I included only some of those. 1.7 is not meant to be
> exhaustive: it can't be. But I did add a bunch you had suggested
> that I had missed on my pass. ]] 

Can you send new 1.7 (or at least list which entries you included, and
which you left out) before putting out new version so we can see which
one you included.

Some of those are important some are not, and I included in my list
all that I tough might be important enough to be mentioned (and yes, I
agree not all of them needs to be there, but those were entries I
assumed someone might think needs to be there, so I think it might be
good idea to get comments now, not only after next revision).

BTW, you didn't anwer to my question what is the intended relationship
between "Appendix D. Significant Changes from RFC 4306" and " 1.7.
Differences Between RFC 4306 and This Document"?

Are you going to remove one of them, or is the 1.7 going to list
only significant changes and Appendix D more changes (including not so
significant). 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 19 Jan 2010 09:12:05 -0500

> extensions, but it should include everything which is defined in this

Agree.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Paul Hoffman <[email-masked]>
Cc:
[email-masked]
Date:
01/19/2010 07:08 AM
Subject:
[IPsec] Notify message types (was: Re: Review of rest of 
draft-ietf-ipsecme-ikev2 (section 2.23.1 forward))

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 14:15:52 -0800

>I agree with Tero, regardless of the discussion we had on where to put the tables etc., the document needs to be internally consistent. So we should add the new notify types that we're defining in *…

Done.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 14:35:03 -0800

>payloads, even though the actual X.509 certificate is not there.

This is a significant technical change from RFC 4306, which clearly makes the two forms alternatives by using the word "unless".

>as not all data is certificates in this payload).

No, that is still a technical change.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 14:47:56 -0800

>Perhaps you can try to write some wording that makes sense...

That makes much more sense. Done.

>Source and Destination Addresses" (section 5.2).

It's a tad late to fix those...

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 14:53:00 -0800

>which you left out) before putting out new version so we can see which

Yes. Given the large set of open issues, I'll publish another draft and give folks time to review it before we pass it along for IETF Last call.

>good idea to get comments now, not only after next revision).

And others thought that some of the ones listed currently are not important enough to list. I have no idea how we will agree on this.

>Differences Between RFC 4306 and This Document"?

I removed Appendix D.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Tue, 19 Jan 2010 22:12:27 -0500

>>>    certificates are available to the sender. The Hash and URL formats
of
>This is a significant technical change from RFC 4306, which clearly makes
>the two forms alternatives by using the word "unless".

Paul, are you saying that the word "unless" means that if the
HTTP_CERT_LOOKUP_SUPPORTED is received that no certificate payloads should
be sent?  That is not consistent with other mailing list discussions,
although that is what the sentence is saying.

Tero's statement is consistent with previous discussions and the
HTTP_CERT_LOOKUP_SUPPORTED Notify which "indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format)."

Based on that description of the HTTP_CERT_LOOKUP_SUPPORTED Notify
and previous posts on the mailing list the sentence that Paul
references has been interpreted by some to mean:

   Certificate payloads containing encoding type 4 SHOULD be included
   in an exchange if
   certificates are available to the sender unless the peer has
   indicated an ability to retrieve this information from elsewhere
   using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

I'm not saying this is right, but that's consistent with previous
posts (most made by Tero).  It also seems to be consistent with the
description of the HTTP_CERT_LOOKUP_SUPPORTED Notify payload.

>No, that is still a technical change.

I'm not sure if this is a technical change or correcting a technical
error.  I agree with the wording Tero has provided and I think that is
what the intent of the original text was.

>--VPN Consortium

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Jan 2010 20:29:23 -0800

At 10:12 PM -0500 1/19/10, David Wierbowski wrote:
>be sent? 

Yes, exactly.

>That is not consistent with other mailing list discussions,

I am glad I am saying what the sentence is saying. We are not supposed to be changing things from 4306, particularly ones with SHOULDs in them.

>error. 

It is not a "technical error", it is a design choice that Tero doesn't like.

>I agree with the wording Tero has provided and I think that is

We disagree here. The point of hash-and-URL was to prevent people from sending certs.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Wed, 20 Jan 2010 00:01:58 -0500

>We disagree here. The point of hash-and-URL was to prevent people from
sending certs.

We do not disagree.  The point of hash-and-URL is to prevent people from
sending certs and it does.  The certificate is not sent when when a
hash-and-URL is used.  A hash and URL of the certificate is sent. That hash
and URL is sent in a certificate payload.  Note you did not say that the
point of hash-and-URL is to prevent people from sending certificate
payloads.  I think Tero's current wording does prevent the cert from being
sent.

Dave Wierbowski

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jan 2010 12:32:32 +0200

> >We disagree here. The point of hash-and-URL was to prevent people from

There are two things here, there is HTTP_CERT_LOOKUP_SUPPORTED and
Hash-and-URL formats. The HTTP_CERT_LOOKUP_SUPPORTED means:

            This notification MAY be included in any message that can
            include a CERTREQ payload and indicates that the sender is
            capable of looking up certificates based on an HTTP-based
            URL (and hence presumably would prefer to receive
            certificate specifications in that format).

Here this "prefer to receive certificate specifications in that
format" is meaning the Hash-and-URL formats.

> payloads.  I think Tero's current wording does prevent the cert from being

Yes.

I.e. if you see HTTP_CERT_LOOKUP_SUPPORTED, you still send Certificate
payloads, but they do not contain full X.509 certificates, they
contain Hash-and-URL of the certificate.

The idea was that you include CERTREQ for X.509 Certificate -
Signature (4) format containing the trust anchor information. Then you
can also include HTTP_CERT_LOOKUP_SUPPORTED notification in the same
packet to indicate that in addition to that format (4), the other end
can also use Hash-and-URL formats as you support fetching the
certificates using HTTP.

Now the other end has two options. If it can provide url for the
certificate (i.e. it for example runs its own http server which
contains the certificate, and it can send hash of the certificate and
make url pointing to that server running and make sure certificate is
available from there), it would be better to use that Hash-and-URL
format.

On the other hand if it is behind NAT, and knows that it cannot start
http-server in such way that other end can reach it, then there is no
point of using hash-and-URL format as the url would not work, so it
can use normal X.509 Certificate - Signature (4) format instead.

Of course the the url could also point to the CA server or some other
server, but the version I described above was one of the intended ways
also (we had discussions on the ipsec list what do to if the http
connection between ipsec peers is not possible, and one solution was
to store the certificate to some other server).
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jan 2010 10:30:54 -0800

>payloads.  I think Tero's current wording does prevent the cert from being

Arrrrgh. "Certificates" vs. "Certificate payloads". I completely missed that in Tero's initial note. This is clearly and editorial problem, I can fix it.

--Paul Hoffman, Director
--VPN Consortium