Subject: Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2009 15:27:12 -0400

Yoav Nir wrote:
> Hi Raj
>  
> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, 
> and then wait for traffic to establish the child SAs.  
>  
> While we do establish an IKE SA if the piggy-backed child SA failed for 
> whatever reason (bad selectors, no proposal chosen), we don't allow for 
> an IKE_AUTH exchange that is missing the child payloads.
>  
> An IKE_AUTH request without the TSi and TSr payloads is 
> considered malformed, and so MUST NOT be processed. Instead, you should 
> reply with INVALID_SYNTAX

   That really seems like a bug in the spec to me.
   I know that in my code I don't get upset about such a situation, as I
have unit test cases that were written when I didn't have child SA code
at all.  I wonder how many implementations really would get upset?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 May 2009 10:52:54 +0300

Michael Richardson wrote:
> Yoav Nir wrote:
> > Hi Raj
> >  
> > Matt is correct. There is no way in IKEv2 to do a phase1-only 
> > exchange, and then wait for traffic to establish the child SAs.
> >  
> > While we do establish an IKE SA if the piggy-backed child SA failed 
> > for whatever reason (bad selectors, no proposal chosen), we don't 
> > allow for an IKE_AUTH exchange that is missing the child payloads.
> >  
> > An IKE_AUTH request without the TSi and TSr payloads is considered 
> > malformed, and so MUST NOT be processed. Instead, you should reply 
> > with INVALID_SYNTAX
> 
>    I know that in my code I don't get upset about such a 
> situation, as I have unit test cases that were written when I 
> didn't have child SA code at all.  I wonder how many 
> implementations really would get upset?

Mine wouldn't. But the spec is adamant. 

Email secured by Check Point

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 May 2009 08:58:59 -0400

Let me suggest a situation where perhaps I would like to bring up
an IKE_SA and not a CHILD_SA: it might be for just sending initial
contact, and perhaps even a DELETE.

I sometimes move quickly from being "outside" my IPsec gateway/firewall
(such as being on wireless), to being wired behind the gateway, where I
do not need IPsec.  The DPD doesn't kick off fast enough, and my traffic
goes to where I am no longer.  It would be nice to bring up the IKE_SA
(or... haha, resume it), just so that I can send a delete and/or
initial_contact. 

Seems like to do this, once needs to include a known-to-be-unacceptable
CHILD_SA proposal.

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 May 2009 16:09:19 +0300

> at all.  I wonder how many implementations really would get upset?

We do.

First thing we do when we receive packet, is to check that all
mandatory payloads (ID, SA, TSi, TSr) are present, and if they are
not, we immediately fail the exchange with INVALID_SYNTAX error.

Also our API is built so that it is immediately to even start IKE SA
creation at all, you start Child SA creation and that automatically
also creates the IKE SA if that is not yet done.

Also I do not consider that bug in specification. The idea is that you
do not create IKE SA before you actually need it, thus only when you
need Child SA. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Wed, 6 May 2009 09:43:52 -0400

> > > Matt is correct. There is no way in IKEv2 to do a phase1-only
exchange,
> > > While we do establish an IKE SA if the piggy-backed child SA failed
for
> do not create IKE SA before you actually need it, thus only when you

We also verify that all mandatory payloads are present before processing
a message and respond with INVALID_SYNTAX if they are not.

Dave Wierbowski

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 May 2009 16:54:12 +0300

Hi Michael 

> Let me suggest a situation where perhaps I would like to 
> bring up an IKE_SA and not a CHILD_SA: it might be for just 
> sending initial contact, and perhaps even a DELETE.
> 
> I sometimes move quickly from being "outside" my IPsec 
> gateway/firewall (such as being on wireless), to being wired 
> behind the gateway, where I do not need IPsec.  The DPD 
> doesn't kick off fast enough, and my traffic goes to where I 
> am no longer.  It would be nice to bring up the IKE_SA (or... 
> haha, resume it), just so that I can send a delete and/or 
> initial_contact. 

A far more common situation is when I'm "outside", not moving anywhere, and I want to connect.  I haven't even opened my mail client yet, or launched the browser (because those thing hate it when the VPN client changes routing to addresses they are trying to reach).

The reason I want to connect before everything else, is that connecting involves some effort (typing the PKCS#12 password, entering a username and password, copying the OTP from the cellphone to the computer...). I want to get this over with, but there's still no packet to derive selectors from.

With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't do Main Mode without attempting Quick Mode.

> Seems like to do this, once needs to include a 
> known-to-be-unacceptable CHILD_SA proposal.

Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed even if the piggy-backed CHILD_SA fails.  

Now I would never suggest that anyone use a traffic selectors type from the private range (241-255) which is almost guaranteed to fail...

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2009 12:54:03 +0300

> (or... haha, resume it), just so that I can send a delete and/or

Or MOBIKE, and just move tunnel end point to your new location.

> Seems like to do this, once needs to include a known-to-be-unacceptable

Or just create valid Child SA, and then send delete to IKE SA which
will take care of the IKE SA and Child SA.

The extra Child SA created there do not really cost anything. The cpu
cost will be few symmetric hashing and macin etc, so I do not really
consider this worth of one extra mode again. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2009 12:58:51 +0300

Yoav Nir writes:
> A far more common situation is when I'm "outside", not moving
> anywhere, and I want to connect.  I haven't even opened my mail
> client yet, or launched the browser (because those thing hate it
> when the VPN client changes routing to addresses they are trying to
> reach). 
> 
> The reason I want to connect before everything else, is that
> connecting involves some effort (typing the PKCS#12 password,
> entering a username and password, copying the OTP from the cellphone
> to the computer...). I want to get this over with, but there's still
> no packet to derive selectors from. 

Most likely in such situations you already have your configuration set
up so you know that you are going to request IP-address from inside,
and you are going to use traffic selectors from that IP-address to the
whole subnet on the other, end so you will propose the any to any
traffic selectors to the server anyways.

Then server will assign IP-address, narrow the traffic selectors down
and then create the Child SA at the same time. All of this could be
tied up to the virtual interface up event, i.e. when you say "ifconfig
vipsec0 up" or similar (or pressing the "Connect" gui button, which
will do the same thing internally), that will trigger the IKE
negotiation and all of this.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 May 2009 14:08:17 +0300

Hi all

I've submitted issue #107 about certificate encoding.

IMO it's not clear how certificate chains are to be encoded in IKEv2.

http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 May 2009 12:33:27 -0700

>http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107

That would be the CertBundle, also described in section 3.6.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 May 2009 00:53:56 +0300

> That would be the CertBundle, also described in section 3.6.

And there's the problem. There is no certificate payload encoding for a certificate bundle. Only hash-and-URL

So what do I do if the peer sent a certificate request for the root CA, and I have a certificate by a sub-CA, and we don't use hash-and-URL?  I can't use a bundle in a Type #4 encoding, but I do need to send the subordinate CA certificate as well.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 May 2009 15:19:20 -0700

>So what do I do if the peer sent a certificate request for the root CA, and I have a certificate by a sub-CA, and we don't use hash-and-URL?  I can't use a bundle in a Type #4 encoding, but I do nee…

You can:

a) start using hash-and-url

b) hope your peer has the sub-CA

c) write an extension to 4306 that allows bundles in CERT

Doing (a) is the most interoperable, but you're probably save with (b) in a typical closed network.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 May 2009 10:00:57 +0300

Paul Hoffman wrote: 
> >And there's the problem. There is no certificate payload 
> encoding for a 
> >certificate bundle. Only hash-and-URL
> >
> >So what do I do if the peer sent a certificate request for 
> the root CA, and I have a certificate by a sub-CA, and we 
> don't use hash-and-URL?  I can't use a bundle in a Type #4 
> encoding, but I do need to send the subordinate CA 
> certificate as well.
> 
> You can:
> 

Or I can go with option (d) and send multiple CERT payloads, as Pasi suggested here: http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html

(thanks, Yaron)

Either way, we should have it clear what is and is not allowed in section 3.6.
Email secured by Check Point

---

From: <[email-masked]>
Date: Mon, 11 May 2009 11:06:35 +0200

Yoav Nir wrote:
> Or I can go with option (d) and send multiple CERT payloads, as Pasi
> suggested here: http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html
> 
> (thanks, Yaron)
> 

I thought this was already clear in RFC 4306, but apparently it's not
as clear as it should be. Section 1.2 says "...might also send its
certificate(s) in CERT payload(s)..." -- so multiple CERT payloads are
allowed -- but Section 3.6 is indeed a bit silent about this.

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 May 2009 12:22:57 +0300

Pasi.Eronen wrote:
> > > Doing (a) is the most interoperable, but you're probably 
> save with 
> > > (b) in a typical closed network.
> > 
> > suggested here: 
> http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html
> > 
> > (thanks, Yaron)
> > 
> I thought this was already clear in RFC 4306, but apparently 
> it's not as clear as it should be. Section 1.2 says "...might 
> also send its
> certificate(s) in CERT payload(s)..." -- so multiple CERT 
> payloads are allowed -- but Section 3.6 is indeed a bit 
> silent about this.
> 
> Best regards,
> Pasi

So how about replacing this:

   o  X.509 Certificate - Signature (4) contains a DER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.

With this:

   o  X.509 Certificate - Signature (4) contains a DER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload. Note that with this encoding if a chain of certificates
      needs to be sent, multiple CERT payloads MUST be used, only the 
      first of which holds the public key used to validate the sender's
      AUTH payload.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 May 2009 15:23:01 +0300

> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107

If certificate chain is sent using X.509 certificate - signature (4)
format, then it is sent as multiple separate CERT payloads.

There is text about this in multiple places in the RFC4306.  In 1.2 it
clearly indicates that there can be multiple CERT payloads and the
first certificate provided must contain the public key used to verify
AUTH field:
----------------------------------------------------------------------
1.2.  The Initial Exchanges
...
   2.15).  It might also send its certificate(s) in CERT payload(s) and
   a list of its trust anchors in CERTREQ payload(s).  If any CERT
   payloads are included, the first certificate provided MUST contain
   the public key used to verify the AUTH field.  The optional payload
...
----------------------------------------------------------------------

and then there is the text you put to the #107:
----------------------------------------------------------------------
3.6.  Certificate Payload
...
      X.509 Certificate - Signature (4) contains a DER encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.
...
   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   first two Hash and URL formats (with HTTP URLs).  Implementations
   SHOULD be capable of being configured to send and accept Raw RSA
   keys.  If multiple certificates are sent, the first certificate MUST
   contain the public key used to sign the AUTH payload.  The other
   certificates may be sent in any order.
...
----------------------------------------------------------------------

So if that format 4 (and 7) is used then multiple CERT payloads are
used and first of the CERT payloads must be the one matching the
public key of the AUTH payload.

If other formats which support bundles are used (RCKS#7 wrapped (1),
hash and url of X.509 bundle (13)) are used then there usually is only
one payload containining the whole chain. As the current document
leaves PCKS#7 wrapped X.509 certificates with very little
specification implementations could also do things differently there
(i.e. wrap each certificate separately or do something else).

For the X.509 bundle I think the format is more clear and only one
CERT payload is sent containing hash and url of all certificates and
crls needed (and first certificate there is the one used for AUTH
payload).

It might be good to add bit more text to the X.509 Certificate -
Signature (4) text, i.e something like: "If multiple certificates are
sent, then each of them is encoded as separate CERT payload.".

Note, that some implementations might send certificates in multiple
formats, i.e. they might send RAW RSA key first, than then provide for
example HASH and URL of X.509 bundle also. Depending on the recipient
it might jsut use the RAW RSA key or might might actually fetch the
bundle and use that.

Note, that the ordering requirement that first certificate provided
MUST contain the public key used to verify AUTH field, is for the
first certificate provided, it is not separately for each certificate
encoding type, i.e. if first "certificate" provided happened to be in
RAW RSA format, then even if the same public key is given out in
different format too (for example as X.509 cetificate), there is no
ordering requirements there anymore. Of course it would be best if
implementations would keep the same order there, i.e. if they include
same public key used in AUTH payload in multiple formats they always
include that first for each certificate type they provide (i.e. the
first X.509 certificate - signature (4) CERT payload has the public
key used in AUTH payload, even when it is not strictly required if
there has already been other CERT payloads before it in different
format).

Smart implementations will simply put all certificates regardless of
format to their "certificate validator", and then take public key from
the first CERT payload (most likely ignoring all they do not
understand) and try to verify if that public key can be verified to be
valid with configured trust anchors.

I do not expect mixing of cert encodings to happen that much, but the
RAW RSA key combined with X.509 certificates might be the exception of
that. I.e. in some environments it might be useful to provide both, so
minimal implementations just use preconfigured RAW RSA key, and other
implementations might actually verify the certificates instead.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 May 2009 15:29:51 +0300

> http://www.vpnc.org/ietf-ipsec/04.ipsec/msg01022.html 

This is what most implementations currently do.

> Either way, we should have it clear what is and is not allowed in

The text is very clear that there CAN be multiple CERT payloads. It is
also very clear that FIRST public key received must be the one
matching the AUTH payload.

Everything else is left as implementation matter.

I do not see any problem there to send multiple CERT payloads each
having one certificate from the end entity cert towards the trust
anchor (usually it is not beneficial to provide the trust anchor
certificate, as it needs to be preconfigured to the recipient
already anyways).
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Mon, 11 May 2009 10:01:06 -0400

> Tero said:

Tero, I do not agree that it is more clear that only one CERT payload would
be sent in the X.509 bundle case.  I agree logically that makes sense, but
the RFC does not mandate that.  In fact the RFC is very vague in the case
of the X.509 bundle.  The RFC does not even clearly state that the first
certificate in the bundle must be used in signing.  An x509 bundle is
simply a sequence of CertificateOrCRL.  It does not impose any order of the
certificates in the bundle, it does not impose any relationship on the
certificates in a bundle, it does not even require certificates to be
within the bundle (i.e. the bundle could just contain a CRL), and it does
not limit the number of CERT payloads that can be sent.

For example assume there was a cert chain CA1->CA2->EE.  An implementation
could decide to use encoding 4 to send the certificate of EE1, to use
encoding 13 to send a URL of a bundle that contains the certificate of CA2
and a CRL issued by CA2, and  to use encoding 13 to send a URL of a bundle
that contains a CRL issued by CA1.  This would be valid according to what
the RFC states.  I'm not saying this should be allowed, but without
additional restrictions in the RFC one must be prepared to deal with this
case.

I'm not opposed to adding text that says:

   When X.509 bundle is used only one certificate payload MUST be sent .
   The first certificate in an X.509 bundle MUST be the certificate used
   when creating the signature contained in the AUTH payload.  Other
   certificates and CRLs in the X.509 bundle SHOULD relate to the CA trust
   chain and may appear in only order.

I think this would simplify processing and not be too restrictive.

Dave Wierbowski

z/OS Comm Server Developer

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 May 2009 17:23:37 +0300

David Wierbowski writes:
> of the X.509 bundle.

I think it is quite obvious that you are not supposed to use multiple
hash and url of X.509 bundle payloads, even when it is not
specifically forbidden. 

> The RFC does not even clearly state that the first certificate in
> the bundle must be used in signing.

That is not true. The 1.2 clearly says:

   ... If any CERT
   payloads are included, the first certificate provided MUST contain
   the public key used to verify the AUTH field.  

Which uses words "first certificate provided", and does not talk about
first CERT payload just because of this.

Again this same thing is reiterated in the 3.6:

   ...  If multiple certificates are sent, the first certificate MUST
   contain the public key used to sign the AUTH payload.  The other
   certificates may be sent in any order.

Again it talks about "first certificate", not first CERT payload.

Note that term "certificate" there is defined so it can be also other
things than certificates, as it said at the beginnig of 3.6:

    ...  Note that the
   term "Certificate Payload" is somewhat misleading, because not all
   authentication mechanisms use certificates and data other than
   certificates may be passed in this payload.

> An x509 bundle is

Otherwise true, but IKE do require the first certificate that
responder sees when going through the CERT payloads and going through
contents of the CERT payloads and going through the URLs the CERT
payload contents might have pointed him to, MUST contain the public
key used to sign the AUTH payload.

That specific MUST is not limited to multiple CERT payloads. It is
MUST specified in 2 different locations and in both cases it talks
about "certificate provided" or just "first certificate". 

> the RFC states.

Yes that is valid as long as the EE1 is the first certificate which is
provided to the recipient. If we take strict interpretation of the 3.6
where also CRLs are in this sense refered as "certificates", there
cannot even be any CRLs before the EE1.

I.e. the first CERT payload MUST either have EE1 as first certificate,
or the URL pointed by it MUST have EE1 as first certificate.

> I'm not saying this should be allowed, but without additional
> restrictions in the RFC one must be prepared to deal with this case.

Yes, your case is allowed, and actually might be efficient way of
doing things, as CA1 and CA2 CRLs might be quite different in size and
might have different update frequencies, thus one of the bundles might
be very static (and large) and another might be updated very often
(but is small). 

> I think this would simplify processing and not be too restrictive.

This would add new MUST (1st one), and reiterate old MUST (2nd one),
and add new SHOULD (3rd one).

I do not think we want to add such text now (I do not see need for it,
and I think it will be too restrictive). 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 May 2009 08:11:29 -0700

>hash and url of X.509 bundle payloads, even when it is not

Fully disagree. We have no prohibition against this, and I can imagine corner cases where it would be useful. If we allow multiple CERT payloads, we cannot discourage particular contents in each payload.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 May 2009 08:09:24 -0700

At 3:23 PM +0300 5/11/09, Tero Kivinen wrote:
>There is text about this in multiple places in the RFC4306. 

...barely. It is only clear in section 1.2, not in subsections of Section 3. The topic of cert chains is barely discussed. I will clear this up in the next draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 May 2009 15:09:25 +0300

Or possibly:

X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate
whose public key is used to validate the sender's AUTH payload. With this
encoding, if a chain of certificates needs to be sent, multiple CERT
payloads of type 4 MUST be used, the first of which holds the public key
used to directly validate the sender's AUTH payload. The other CERT payloads
contain the other components of the chain in natural order, i.e. each
certificate signing the preceding one.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yoav Nir
> Sent: Monday, May 11, 2009 12:23
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [IPsec] Issue #107
> 
> Pasi.Eronen wrote:
> >
> > Yoav Nir wrote:
> > > > You can:
> > > >
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 May 2009 08:57:36 -0700

>certificate signing the preceding one.

In a word: no. This is a new requirement on a topic that was vague before.

It should be sufficient for us to say something in 3.6 about multiple CERT payloads being acceptable, and probably (but not necessarily) the correct way to send a PKIX chain if the party believes that it is needed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 May 2009 00:19:41 +0300

In two words, why not? What is the exact new requirement you are referring
to?

More generally, this is not some obscure part of the RFC that we're
discussing. This is possibly the most mainstream usage scenario. And we need
to make every effort possible in order to ensure interoperability.

Thanks,
	Yaron

> Paul Hoffman
> Sent: Monday, May 11, 2009 18:58
> To: [email-masked]
> certificate
> It should be sufficient for us to say something in 3.6 about multiple CERT
> payloads being acceptable, and probably (but not necessarily) the correct
> way to send a PKIX chain if the party believes that it is needed.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 May 2009 14:55:06 -0700

>In two words, why not? What is the exact new requirement you are referring

"multiple CERT payloads of type 4 MUST be used". That is a new requirement.

>discussing. This is possibly the most mainstream usage scenario.

I suspect not. From what I have heard from VPNC members over the years:
  preshared secrets >>
  certs issued directly from a trust anchor >
  certs in a hierarchy
(Where EAP fits in this list varies wildly between vendors)

>And we need

Fully agree. That's why I think it is important to not create new MUSTs for this, but to expect implementers to be able to handle validation chains in a variety of sensible fashions.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2009 11:52:23 +0300

Paul Hoffman writes:
> It should be sufficient for us to say something in 3.6 about
> multiple CERT payloads being acceptable, and probably (but not
> necessarily) the correct way to send a PKIX chain if the party
> believes that it is needed. 

Yes, it might be better to say at the beginning of the section 3.6
that multiple CERT payloads is allowed, and if CERT encoding is such
that it can only encode one certificate then multiple CERT payloads is
the way to send the chains. If encoding can handle multiple
certificates (Hash and URL of X.509 bundle), then the whole
certificate chain (and associated CRLs if needed) can be sent as one
CERT payload (or split to multiple pieces if needed). There can also
be multiple CERT payloads with different encodings.

Sending multiple CERT payloads is not only restricted to X.509
Certificate - Signature (4) format, and because of this the text
should be at the beginning of 3.6 section.

Note, that 3.6 explicitly says that except the first certificate, all
other certificates can be in any order.
-- 
[email-masked]

---

From: raj singh <[email-masked]>
Date: Fri, 15 May 2009 10:12:55 +0530

Hi Yoav,

If check for mandatory payloads per exchange type is MUST, if it fails we
MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft
? Putting it clearly in the draft make more sense and avoids many
confusions.

Thanks,
Raj

On Wed, May 6, 2009 at 7:24 PM, Yoav Nir <[email-masked]> wrote:

> A far more common situation is when I'm "outside", not moving anywhere, and
> I want to connect.  I haven't even opened my mail client yet, or launched
> the browser (because those thing hate it when the VPN client changes routing
> to addresses they are trying to reach).
>
> The reason I want to connect before everything else, is that connecting
> involves some effort (typing the PKCS#12 password, entering a username and
> password, copying the OTP from the cellphone to the computer...). I want to
> get this over with, but there's still no packet to derive selectors from.
>
> With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't
> do Main Mode without attempting Quick Mode.
>
> Now I would never suggest that anyone use a traffic selectors type from the
> private range (241-255) which is almost guaranteed to fail...
>
> Yoav

---

From: raj singh <[email-masked]>
Date: Fri, 15 May 2009 15:04:22 +0530

Hi Team,

One more question.
The INVALID_SYNTAX notify in response to missing payload in IKE_AUTH should
be send encrypted using DH keys or unencrypted ?

Thanks,
raj

On Fri, May 15, 2009 at 10:12 AM, raj singh <[email-masked]> wrote:

>> A far more common situation is when I'm "outside", not moving anywhere,
>> and I want to connect.  I haven't even opened my mail client yet, or
>> launched the browser (because those thing hate it when the VPN client
>> changes routing to addresses they are trying to reach).
>>
>> Now I would never suggest that anyone use a traffic selectors type from
>> the private range (241-255) which is almost guaranteed to fail...
>>
>> Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 May 2009 15:05:55 +0300

> be send encrypted using DH keys or unencrypted ?

As it is clear that other end is not following the specification, i.e.
there is bug on the other end, there is no need to think that much
what you should do in that case. That situation never happens in
normal case, so use the easiest way out.

For me that is silently destroy the IKE SA without sending any error
codes back. There is debug prints indicating the problem (but nothing
for release build).

There is no point of thinking what to do in situations that only
happens during interop testing events when testing against broken
implementations... Just make sure your implementation cleanly clears
the situation (i.e. does not crash, or read uninitialized buffers
etc) and thats it.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 May 2009 10:34:57 -0400

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    >> The INVALID_SYNTAX notify in response to missing payload in
    >> IKE_AUTH should be send encrypted using DH keys or unencrypted ?

    Tero> As it is clear that other end is not following the
    Tero> specification, i.e.  there is bug on the other end, there is
    Tero> no need to think that much what you should do in that
    Tero> case. That situation never happens in normal case, so use the
    Tero> easiest way out.

  I agree with the general principle.
  However, a log entry would be good, as there will be people with
broken implementations (i.e. "bugs") out there trying to determine what
is going on, and they won't always be sitting at a table next to you.