Re: [IPsec] Failure Detection - issue #202

[David Wierbowski]

I agree with Tero that the section is confusing and very difficult to
follow.  I have taken a stab at rewording it.  I think this still
incorporates the blending of the two approaches  that Paul attempted, but
flows better and makes it easier to understand.  I'm not sure it addresses
all of Tero's concerns, but I hope it gets us closer.

A token maker MUST NOT send a QCD token in an unprotected
message for an existing IKE SA.

This requirement is obvious and easy in the case of a single gateway.
However, some implementations use a load balancer to divide the load
between several physical gateways.  In such configuration it MUST NOT
be possible to trick one gateway into sending a QCD token for an
IKE SA which exists on another gateway.  This is true whether the
an attacker uses the token taker's IP address or a different IP
address.

Because it includes the token taker's IP address in the token
generation, the method in Section 5.2 prevents revealing the QCD
token for an existing pair of IKE SPIs to an attacker who is using a
different IP address.  Note that the use of this method causes the
tokens to be invalidated whenever the token taker's address changes.
It is also important to note that this method does not prevent
revealing the QCD token to a man-in-the-middle attacker who is
spoofing the token taker's IP address. Such an attacker may attempt
to direct messages to a cluster member other than the member
responsible for the IKE SA in an attempt to trick that gateway into
sending a QCD token for an existing IKE SA.

IPsec Failure Detection is not applicable to deployments where the QCD
token is shared by multiple gateways and the gateways cannot assess
whether the token can be legitimately sent in the clear while another
gateway may actually still own the SA's. Load balancer configurations
typically fall in this category.  In order for a load balancing
configuration of IPsec gateways to support this specification,
all members MUST be able to tell whether a particular IKE SA is active
anywhere in the cluster.  One way to do it is to synchronize a list of
active IKE SPIs among all the cluster members.




Dave Wierbowski


z/OS Comm Server Developer

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






From:   Tero Kivinen 
To: Paul Hoffman 
Cc: ipsec@ietf.org
Date:   02/11/2011 06:38 AM
Subject:Re: [IPsec] Failure Detection - issue #202
Sent by:ipsec-boun...@ietf.org



Paul Hoffman writes:
> 9.2.  QCD Token Transmission
>
> A token maker MUST NOT send a valid QCD token in an unprotected
> message for an existing IKE SA.
>
> This requirement is obvious and easy in the case of a single gateway.
> However, some implementations use a load balancer to divide the load
> between several physical gateways.  It MUST NOT be possible even in
> such a configuration to trick one gateway into sending a valid QCD
> token for an IKE SA which is valid on another gateway.  This is true
> whether the attempt to trick the gateway uses the token taker's IP
> address or a different IP address.
>
> Because it includes the token taker's IP address in the token
> generation, the method in Section 5.2 prevents revealing the QCD
> token for an existing pair of IKE SPIs to an attacker who is using a
> different IP address.  Note that the use of this method causes the
> tokens to be invalidated whenever the token taker's address changes.
> It is important to note that this method does not prevent revealing
> the QCD token to a man-in-the-middle attacker who is spoofing the
> token taker's IP address, if that attacker is able to direct messages
> to a cluster member other than the member responsible for the IKE SA.
>
> This document does not specify how a load-sharing configuration of
> IPsec gateways would work, but in order to support this
> specification, all members MUST be able to tell whether a particular
> IKE SA is active anywhere in the cluster.  One way to do it is to
> synchronize a list of active IKE SPIs among all the cluster members.
>
> If an attacker can somehow access a QCD token while the SA's are
> still active, this attacker will be able to tear down the sessions at
> will. In particular, avoiding false positives is critical to the
> security of the proposal and a token maker MUST NOT send a QCD token
> in an unprotected message for an existing IKE SA. IPsec Failure
> Detection is thus not applicable to deployments  where the QCD token
> is shared by multiple gateways and the gateways can not assess
> whether the token can be legitimately sent in the clear while another
> gateway may actually still own the SA's. Load balancer designs
> typically fall in this category.

I think the section is bit confusing. It says similar (or perhaps
same, I am not sure) things in different places using different words,
so it is not really clear what it is saying.

In general I think that section needs rewrite, and the problem is that
nobody really has real overall picture what should be in i

Re: [IPsec] Fwd: Failure Detection - issue #202

[David Wierbowski]

I'm not sure what Frederic means by this statement should "be moved under
Security Considerations."  Section 9.2 is already in the Security
Considerations section.

As far as his proposed text, I feel that Scott's text does a better job
describing the concern.  Frederic's own text does not help with his concern
of hiding the complexity in the statement that "all members MUST be able to
tell whether a particular IKE SA is active anywhere in the cluster."  He
just reworded the statement to be "Practically, IPsec Failure Detection is
thus not applicable to deployments  where the QCD token is shared by
multiple gateways and the gateways can not assess whether the token can be
legitimately sent in the clear while another gateway may actually still own
the SA's."Both statements mean the same thing and impose the same
requirement.

If consensus is that others prefer Frederic's statement over the one that
Scott provided us, then I believe the "Practically" should be deleted from
the sentence that I mentioned above and the last sentence should be changed
to, "Load balancer designs may fall in this category."  I don't think we
should presume to know what is typical in load balancers.


Dave Wierbowski


z/OS Comm Server Developer

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






From:   Yoav Nir 
To: "ipsec@ietf.org" 
Date:   02/01/2011 04:30 PM
Subject:[IPsec] Fwd:  Failure Detection - issue #202
Sent by:ipsec-boun...@ietf.org



Adding the IPsec list.

Begin forwarded message:

  From: Frederic Detienne 
  Date: February 1, 2011 9:37:33 PM GMT+02:00
  To: Paul Hoffman 
  Cc: Yoav Nir , Pratima Sethi ,
  Yaron Sheffer 
  Subject: Re: [IPsec] Failure Detection - issue #202

  Hi Paul, Yoav,

  thanks. We are rather puzzled and have been debating how to address
  this.

  The proposal should either properly support Load Balancers or should
  step down and rule out that use case.

  The statement:

  -8<---
  IPsec gateways would work, but in order to support this
specification, all members MUST be able to tell whether
  a particular
IKE SA is active anywhere in the cluster

  -8<---

  Hides a lot of complexity behind a single sentence. This sentence
  actually makes Failure Detection impractical. Simplicity of
  implementation (as compared to SA state synchronization) were key
  drivers for us in this proposal.

  The statement should be more precise about the general scenario and
  be moved under Security Considerations.

  -8<---
  If an attacker can somehow access a QCD token while the SA's are
  still active, this attacker will be able to tear down the sessions at
  will. In particular, avoiding false positives is critical to the
  security of the proposal and a token maker MUST NOT send a QCD token
  in an unprotected message for an existing IKE SA.

  Practically, IPsec Failure Detection is thus not applicable to
  deployments  where the QCD token is shared by multiple gateways and
  the gateways can not assess whether the token can be legitimately
  sent in the clear while another gateway may actually still own the
  SA's. Load balancer designs typically fall in this category.
  -8<---

  thanks and regards,

  Frederic

  On 01 Feb 2011, at 17:51, Paul Hoffman wrote:

Pratima and Frederic: Please respond to Yaron and I ASAP,
either way, whether or not you agree with the wording. Given
that this was your issue and you did not comment during WG LC,
we are concerned that we have lost contact with you.

If you do not agree with the wording, you need to say so on the
mailing list before Friday.

--Paul Hoffman

On 2/1/11 7:05 AM, Yoav Nir wrote:
  Hi all.

  Following last week's conf call, Scott Moonen has
  proposed text to resolve issue #202. The idea is to
  remove section 9.4 entirely, and change section 9.2 as
  follows:


  OLD:

  9.2.  QCD Token Transmission

A token maker MUST NOT send a QCD token in an
  unprotected message for
an existing IKE SA.  This implies that a conforming QCD
  token maker
MUST be able to tell whether a particular pair of IKE
  SPIs represent
a valid IKE SA.

This requirement is obvious and easy in the case of a
  single gateway.
However, some implementations use a load balancer to
  divide the load
between several physical gateways.  It MUST NOT be
  possible even in
such a

Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB

[David Wierbowski]

Scott,

I agree that there is relationship between sections 9.2 and 9.4. The
statement that "all members MUST be able to tell whether a particular IKE
SA is active anywhere in the cluster" which is found in 9.2 is consistent
with my comment that " the algorithms in 5.1 and 5.2 should not be used in
cases where load balancing cluster members share the same QCD token and do
not share IKE SA state."  Although I suppose I should have said same
QCD_SECRET instead of QCD token  to be more accurate.

I could see why you would say that the algorithm in 5.2 as justified in
section 9.4 is being used to meet the requirement that "A token maker MUST
NOT send a QCD token in an unprotected message for an existing IKE SA."
Certainly if we do not include IP address it is possible that a cluster
member could send the QCD token of an existing IKE SA to an attacker using
a different source IP address.  In that case we'd be unknowingly violating
the rule.  By adding the ip address of the taker we prevent this.

I think you are correct that the two sections could be combined, but I'll
defer to Yoav on that.

As an aside I see that I cut and paste the wrong paragraph in my append.  I
had actually intended to cut and paste the last paragraph of 9.4 and I now
see that I cut and paste the next to last paragraph in section 9.4 :>).

Dave Wierbowski




From:   Scott C Moonen/Raleigh/IBM@IBMUS
To: David Wierbowski/Endicott/IBM@IBMUS
Cc: "ipsec@ietf.org" , ipsec-boun...@ietf.org, Yoav
Nir 
Date:   01/13/2011 09:50 AM
Subject:Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by:ipsec-boun...@ietf.org



Combining the two sections could also make it clearer that 5.2/9.4 may not
be a "complete" solution for any given environment. The approach of 5.2/9.4
solves the problem of an independent attacker using a different source IP
address, but not a proximate/MitM attacker as is currently addressed in
9.2.


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

(Embedded image moved to file: pic34804.gif)Inactive hide details for Scott
C Moonen---01/12/2011 03:54:03 PM---I wonder if there's a way to merge
sections 9.2 and 9.4.  IScott C Moonen---01/12/2011 03:54:03 PM---I wonder
if there's a way to merge sections 9.2 and 9.4. I think that using the
algorithm in 5.2 as

From: Scott C Moonen/Raleigh/IBM
To: David Wierbowski/Endicott/IBM@IBMUS
Cc: "ipsec@ietf.org" , ipsec-boun...@ietf.org, Yoav Nir

Date: 01/12/2011 03:54 PM
Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB


I wonder if there's a way to merge sections 9.2 and 9.4. I think that using
the algorithm in 5.2 as specified in 9.4 is really just an extension of
this requirement from section 9.2: "A token maker MUST NOT send a QCD token
in an unprotected message for an existing IKE SA."

It might be possible to remove a lot of the detail in 9.4 and generalize
9.2 to hint at there being several ways of solving this problem -- 9.2's
state synchronization and 5.2/9.4's including the remote IP address.


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


(Embedded image moved to file: pic11871.gif)Inactive hide details for David
Wierbowski---01/11/2011 12:39:21 PM---I agree with Tero that it is unsafe
to assume how a load David Wierbowski---01/11/2011 12:39:21 PM---I agree
with Tero that it is unsafe to assume how a load balancer decides to
distribute traffic. Si

From: David Wierbowski/Endicott/IBM@IBMUS
To: "ipsec@ietf.org" , ipsec-boun...@ietf.org
Cc: Yoav Nir 
Date: 01/11/2011 12:39 PM
Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by: ipsec-boun...@ietf.org



I agree with Tero that it is unsafe to assume how a load balancer decides
to distribute traffic.  Since section 9.4 (previously 10.4) is in the
Security Considerations section it seems reasonable to me that we'd warn
that the algorithms in 5.1 and 5.2 should not be used in cases where load
balancing cluster members share the same QCD token and do not share IKE SA
state.

I don't think this restriction precludes the use of QCD in the hot-standby
cluster scenario that Yoav mentioned in his previous append.  By definition
in a hot-standby cluster only one of the cluster members is active at any
one time and it is not doing load balancing with its standby members.

In the same append Yoav stated that to achieve scalability with your hot
standby-cluster, you implement load sharing.  If you add load balancing to
your hot standby-cluster then the warning in the previous paragraph
applies.  In otherwords if you want one of your standby members to be a
load balancing target for the activ

Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB

[David Wierbowski]

I agree with Tero that it is unsafe to assume how a load balancer decides
to distribute traffic.  Since section 9.4 (previously 10.4) is in the
Security Considerations section it seems reasonable to me that we'd warn
that the algorithms in 5.1 and 5.2 should not be used in cases where load
balancing cluster members share the same QCD token and do not share IKE SA
state.

I don't think this restriction precludes the use of QCD in the hot-standby
cluster scenario that Yoav mentioned in his previous append.  By definition
in a hot-standby cluster only one of the cluster members is active at any
one time and it is not doing load balancing with its standby members.

In the same append Yoav stated that to achieve scalability with your hot
standby-cluster, you implement load sharing.  If you add load balancing to
your hot standby-cluster then the warning in the previous paragraph
applies.  In otherwords if you want one of your standby members to be a
load balancing target for the active member in the cluster then you need to
share the IKE SA state between the active member and the standby member.

I'd recommend that the following text from 9.4 be changed:

   To thwart this possible attack, such configurations should use a
   method that considers the taker's IP address, such as the method
   described in Section 5.2.



Dave Wierbowski




From:   Yoav Nir 
To: "ipsec@ietf.org" 
Date:   01/10/2011 03:04 AM
Subject:[IPsec] Issue #202: Token makers generating the same tokens
without synchronized DB
Sent by:ipsec-boun...@ietf.org



Greetings.

We have just submitted version -03 of the draft.  This closes issues, #198,
#199, #200, and #201.

Which leaves us with just one issue: #202


= Issue #202: Token makers generating the same tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways share
the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases, so
a fail-over is very much like a reboot - the IKE SA is gone, and QCD is
effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a member
that does not own the IKE SA to send the QCD token to an attacker. The
attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP
address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and that
predicting or prescribing load balancer behavior in inherently dangerous.
===

Please send your opinions to the list. This one actually addresses the
scope of the document, so it's strange that this comes up as the last
issue, but we still have to decide on this.

Yoav


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #199 - Section 7.4 is mostly wrong

[David Wierbowski]

Yoav,

I think preserving the history is worthwhile.  I'm fine with moving section
7 to an appendix.  With
that said Tero will still object to the text that would become A1.4
(currently 7.4).  The text in
Section 7.4 represents our opinion which is not the same as his.  I think
the text should be
modified to acknowledge that some implementations may reduce their timeout
due to INVALID_SPI
or INVALID_IKE_SPI, but we feel this still results in an unnecessary delay
that could be eliminated
with use of QCD tokens.  I suggest the following replacement text:

   Some implementations require fewer retransmissions over a
   shorter period of time for cases of liveness check started because of
   an INVALID_SPI or INVALID_IKE_SPI notification.

   We believe that the default retransmission policy should represent a
   good balance between the need for a timely discovery of a dead peer,
   and a low probability of false detection.  We expect the policy to be
   set to take the shortest time such that this probability achieves a
   certain target.  Therefore, we believe that reducing the elapsed time
   and retransmission count may create an unacceptably high probability of
   false detection, and this can be triggered by a single INVALID_IKE_SPI
   notification.

   Additionally, even if the retransmission policy is reduced to, say,
   one minute, it is still a very noticeable delay from a human
   perspective, from the time that the gateway has come up (i.e. is able to

   respond with an INVALID_SPI or INVALID_IKE_SPI notification) and until
the
   tunnels are active, or from the time the backup gateway has taken
   over until the tunnels are active.  The use of QCD tokens can reduce
this
   delay.


Dave Wierbowski






From:   Yoav Nir 
To: IPsecme WG 
Date:   12/02/2010 05:34 AM
Subject:[IPsec] Issue #199 - Section 7.4 is mostly wrong
Sent by:ipsec-boun...@ietf.org



Hi all

This issue is about some of the wording of section 7.4. I don't agree that
this is mostly wrong, but I think the group's energies are better spent
elsewhere. Section 7, in its entirety is about alternative solutions that
were not adopted.

I think we can either delete the whole section, or else move it to an
appendix.

What do others think?

Yoav
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #194 - Security Considerations should discuss the threat

[David Wierbowski]

Yaron/Yoav,

Thanks for your answers, but I should have been more specific in my
question.  I was not asking how a MITM could break IKE.  I was asking for
an example of how draft-ietf-ipsecme-failure-detection-01 increases the
risk over what we have today in IKE.  That's what I'm not seeing.

An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA  request)
and forge an informational message back to the requester containing  N
(INVALID_IKE_SPI) and N(QCD_TOKEN).  If he guesses QCD_TOKEN correctly he
can disrupt the IKE_SA and force a negotiation.   So in theory this makes
IKE more prone to a passive MITM, but that's theory.  Given significant
randomness in the token the attack is not feasible.  If there's a flaw in
the RFC that makes tokens easy to guess this would be a valid attack.
True, if we do not mandate the algorithm somebody can implement a token
generation scheme that is easy to guess.

Yaron are you saying that we need to explain the possible attack so one
does not implement a trivial token generation algorithm?  I tend to agree
with Yoav, that we do that in the first paragraph of 10.1.  Even with your
forced hand I'm not sure what you are looking for :>),

Do you know of a way that the draft allows an attacker to disrupt an
existing IKE session or learn of non-public information about the peers?

Dave Wierbowski


z/OS Comm Server Developer

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






From:   Yaron Sheffer 
To:     Yoav Nir 
Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG

Date:   10/20/2010 10:21 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat



In fact I was referring to the whole extension. OK, since you're forcing
my hand...

General

The mechanism must not reduce the security of IKEv2 or IPsec.
Specifically, an eavesdropper must not learn any non-public information
about the peers.

DoS Resistance

The proposed mechanism should be secure against attacks by a passive
MITM (eavesdropper). Such an attacker must not be able to disrupt an
existing IKE session, either by resetting the session or by introducing
significant delays.

The mechanism need not be similarly secure against an active MITM, since
this type of attacker is already able to disrupt IKE sessions.

Thanks,
 Yaron

On 10/20/2010 03:58 PM, Yoav Nir wrote:
> OK. I did not understand that this was about 5.2 rather than the whole
extension.
>
> In that case, does section 10.4 address this?  If not, can you suggest
some text?
>
> Yoav
>
> On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote:
>
>> Hi Dave,
>>
>> an active MITM, i.e. the sys admin at your local Starbucks, needs to
>> only drop a few packets of an open IKE SA (a few retransmissions) for
>> the peers to decide that they have a problem and attempt to renegotiate
>> the SA. This attack is trivial to mount if you're at the right spot.
>>
>> On the other hand, Sec. 5.2 of the document is designed to prevent
>> another kind of DoS attack that eventually does the same thing: resets
>> the SA.
>>
>> So we need to explain why we add a mechanism to prevent one kind of DoS
>> attacks even though we have other potential DoS issues. I'm not saying
>> this is wrong, I'm saying it needs to be rationalized.
>>
>> Thanks,
>>   Yaron
>>
>> On 10/20/2010 02:57 PM, David Wierbowski wrote:
>>> I'm not sure I understand Yaron's concern.  Yaron, can you elaborate
how a
>>> MITM attacker can easily cause an IKE SA to be reset?  I would think he
>>> could only do so if he hi-jacked the original  IKE_SA negotiation and
is
>>> now impersonating the remote security endpoint.  In that case you have
>>> bigger issues.
>>>
>>> Dave Wierbowski
>>>
>>>
>>>
>>>
>>> From:   Yoav Nir
>>> To: IPsecme WG
>>> Date:   10/20/2010 04:10 AM
>>> Subject:Re: [IPsec] Issue #194 - Security Considerations should
discuss
>>>  the threat
>>> Sent by:ipsec-boun...@ietf.org
>>>
>>>
>>>
>>> One week, and no replies...
>>>
>>> I will leave this issue open unless I get some suggested security
>>> considerations text.
>>>
>>> The first paragraph in section 10.1 says the following. What else is
>>> missing?
>>>
>>> Tokens MUST be hard to guess.  This is critical, because if an
>>> attacker can guess the token associated with an IKE SA, she can
tear
>>> down the IKE SA and associated tunnels at will.  When the token is
>>> delivered in the IKE_AUTH exchange, it is e

Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193

[David Wierbowski]

I think it is fine to not mandate a particular method of token generation.
I think it is sufficient to provide two recommendations with an applicable
explanation of pros and cons.  I do not think this will lead implementers
to  make security-critical design mistakes.  Most implementers can read an
RFC and understand the issues.  When in doubt they post a question here.

Dave Wierbowski




From:   Yoav Nir 
To: IPsecme WG 
Date:   10/20/2010 04:10 AM
Subject:Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue
193
Sent by:ipsec-boun...@ietf.org



Hi all

I have started this thread about this issue a week ago, and so far the only
responses we have had are from Yaron and Frederic. I would like to hear
some more, because this issue is very central.

Here's a summary of my take on this issue.

The draft does not mandate any particular method of token generation (in
this, we follow the example of the stateless cookie in RFC 5996). It does,
however, suggest two such methods, both of which are somewhat similar to
the cookie generation method suggested in RFC 5996:

1. The method in section 5.1 involves hashing a secret with the IKE SPIs
2. The method in section 5.2 involves hashing a secret with the IKE SPIs
and the token taker's IP address.

The big disadvantage of the method in 5.2 is that whenever the token
taker's IP address changes (as is common for roaming clients) the Token has
to be replaced. The advantage is that in a certain configuration (details
below) it prevents a token discovery attack. This attack involves tricking
one gateway to send a clear QCD token for an IKE SA owned by another
gateway. If a cluster is located behind a load balancer, at attacker can
attempt to send fake IKE messages from various IP addresses, until those
requests reach the "wrong" gateway, which will generate a QCD token that
can be used to cause the original token taker to disconnect.

Details of this scenario: For this attack to take place, we need all of the
following:
 - A group of gateways, all sharing the same QCD token secret.
 - A disjoint IKE SA database, meaning that IKE SAs are not synchronized.
One member in this cluster cannot know if a particular IKE SA exists on
another member.
 - The ability of an attacker to direct requests to different members
(either by varying its IP address or by directly addressing the member),
and a willingness of all members to reply with a QCD token.

We are not saying that having such no-sync clusters is a good idea. In
fact, it may be a good idea to recommend against them in the ipsecha
document. But they do exist. I have no problem recommending that
implementations that don't have such concerns just go ahead and implement
the method in 5.1, but since these things do exist, I think it's OK to
recommend the method in 5.2 for these configurations.  Frederic is
apparently with me on this, which is good. Yaron has some doubts, though,
and we'd really like to hear what other people think.

Yoav

On Oct 17, 2010, at 9:29 PM, Frederic Detienne wrote:

>
> This type of debate happened before and once again, it is critical to
design a secure protocol rather than a protocol that can/may be implemented
securely.
>
> The rejoinder is to
> - offer recommended cookie computation methods
> - highlight the risks of each method and the risks of doing something
else
>
> This way, those who follow the spec can ascertain their computation
method is secure and has a well defined domain of applicability.
>
> I feel the draft is headed in the right direction.
>
> If we take out computation methods, we probably ought to restrict the
domain of applicability of the specification and/or spend more time
highlighting the risk of do-it-yourself cookie methods. Neither option
looks attractive.
>
> Notice the problem of address-less cookie is not limited to load balanced
clusters. If the attacker can somehow target a device owning the QCD
cookie-generating-key but not owning the SA, this attacker may gain access
to the QCD token for a given SPI. This applies _for instance_ to HSRP pairs
if the real addresses of the devices are accessible by the attacker and if
the standby device accepts connections. This is just an example but it is
likely to affect many implementations in practice.
>
> The address-less method will likely require more severe warnings in order
to restrict or constraint its domain of applicability.
>
> regards,
>
>fred
>
> On 17 Oct 2010, at 15:41, Yoav Nir wrote:
>
>>
>> On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote:
>>
>>> Hi Frederic,
>>>
>>> I understand the scenario now and I agree that a solution is needed.
But
>>> I have two issues, one general and one specific:
>>>
>>> - Even though there are no interoperability implications, I think we
>>> should specify the token format. This will prevent people from making
>>> some security-critical design mistakes. In other words, we should have
>>> *one* token generation method.
>>
>> Since the

Re: [IPsec] Issue #194 - Security Considerations should discuss the threat

[David Wierbowski]

I'm not sure I understand Yaron's concern.  Yaron, can you elaborate how a
MITM attacker can easily cause an IKE SA to be reset?  I would think he
could only do so if he hi-jacked the original  IKE_SA negotiation and is
now impersonating the remote security endpoint.  In that case you have
bigger issues.

Dave Wierbowski




From:   Yoav Nir 
To: IPsecme WG 
Date:   10/20/2010 04:10 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
Sent by:ipsec-boun...@ietf.org



One week, and no replies...

I will leave this issue open unless I get some suggested security
considerations text.

The first paragraph in section 10.1 says the following. What else is
missing?

   Tokens MUST be hard to guess.  This is critical, because if an
   attacker can guess the token associated with an IKE SA, she can tear
   down the IKE SA and associated tunnels at will.  When the token is
   delivered in the IKE_AUTH exchange, it is encrypted.  When it is sent
   again in an unprotected notification, it is not, but that is the last
   time this token is ever used.

Yoav

On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote:

> Yaron: The security considerations are focused on details of the QCD
solution, rather then on the threats we are dealing with. These threats are
non-trivial to describe, since an active MITM attacker can easily cause an
IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be
able to do so. We need to analyze the threats in order to select a secure,
but not overly complex solution.
>
>
>
> Suggested text would be most welcome.
>
> Yoav
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #189 - Reply is not needed for unprotected message containing QCD

[David Wierbowski]

Yoav,

Just for posterity, I agree with Scott's suggestion.

Dave Wierbowski






From:   Yoav Nir 
To: IPsecme WG 
Date:   09/30/2010 04:20 PM
Subject:Re: [IPsec] Issue #189 - Reply is not needed for unprotected
message containing QCD
Sent by:ipsec-boun...@ietf.org



OK. there were zero responses to this. Since this seems obvious to me, I
will correct it as Scott suggests, and close the issue with the publication
of -01.

On Sep 21, 2010, at 2:58 PM, Yoav Nir wrote:

> Hi all.
>
> We're starting discussions of the issues that are open for the failure
detection draft.
>
> Reported by Scott C Moonen:
>
> What is the purpose of sending an empty response to the unprotected N
(INVALID[_IKE]_SPI)&N(QCD_TOKEN)+ message? I'm not sure it provides any
real value and would really prefer not to send it. Also, this contradicts a
few "MUST NOT" statements in ikev2bis concerning how we handle unprotected
messages; if the consensus is to keep this behavior then we should make
clear that we are self-consciously breaking the rules here.
>
>
> What Scott is referring to is the last paragraph of section 4.5:
>   If the QCD_TOKEN verifies OK, an empty response MUST be sent.  If the
>   QCD_TOKEN cannot be validated, a response MUST NOT be sent.
>   Section 5 defines token verification.
>
>
> I believe Scott is right. I don't know what I was thinking when I wrote
this. In fact, I believe the name of the section should be changed (from
"Presenting the Token in an INFORMATIONAL Exchange") because this is not an
INFORMATIONAL exchange.
>
> If you can think of a reason why this needs to be like this instead of
the following, please reply.
>
>   If the QCD_TOKEN verifies OK, the IKE SA and its associated Child SAs
>   MUST be silently discarded. If the QCD_TOKEN cannot be validated, the
>   Notification MUST be ignored, and the incident MAY be logged.
> ___

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #192 - RFC 2119 language in section 9.1

[David Wierbowski]

I agree that the RFC 2119 language in this section is not appropriate.  To
me this is just stating where it makes sense to implement the maker/taker
roles.  You also know my opinion about bullet 3.  I think an implementer
should be able to decide what roles make sense for their implementation.


Dave Wierbowski






From:   Yoav Nir 
To: IPsecme WG 
Date:   09/30/2010 04:35 PM
Subject:[IPsec] Issue #192 - RFC 2119 language in section 9.1
Sent by:ipsec-boun...@ietf.org



Reported by Yaron Sheffer:

9.1: this is not really a MUST, let's use some non-RFC 2119 wording.

Yoav Nir: I disagree. We are giving requirements for implementations that
conform to this spec. The requirements vary by the role that the
implementation plays: RA client, RA gateway, Site to site gateway, or host.



The "offending" section is given below:
   To clarify the requirements:
   o  A remote-access client MUST be a token taker and MAY be a token
  maker.
   o  A remote-access gateway MAY be a token taker and MUST be a token
  maker.
   o  An inter-domain VPN gateway MUST be both token maker and token
  taker.


Unlike previous issues, this one has differences of opinion (between me and
Yaron). Please post your opinions to the list (I think I know Tero's
opinion on the third bullet point at least...)

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00

[David Wierbowski]

Tero writes:
>David Wierbowski writes:
>> Tero writes:
>> >I do not consider very open protocols which allow all kind of things
>> >"just for fun" and "in case we someday get scenario which can use it"
>> >as good thing.
>>
>> I do not think we are allowing the initiator and responder to
>> be both a taker and a maker just for fun.  There are cases where
>> either side can initiate and it makes sense in those cases.
>
>Can you give example of such setup, preferrable something that I have
>not already covered in my previous emails and explained why QCD is not
>needed there.

Consider a business partner relationship where data exchanged between
the partners are protected by IPsec.  In these environments it is often
common for either end to initiate a negotiation and for either end to
initiate sending data.  For example perhaps they share a process
management system or order fulfillment system.  One end might initiate
a connection to submit an request/order.  Days later the other end might
initiate a connection to indicate the fulfillment of the request/order.
There truly envirnoments that do and can initiate from either end.

The ability to initiate an IKE_SA is not the only case where allowing
both endpoint be takers and makers is applicable.  Consider the
following:

Host (responder) <==> GW (initiator) <---> Client

The Client is connecting to the Host.  The GW chooses to initiate a
single SA per client behind the GW.  The Client's connection has data
streaming in from the host -- perhaps the Client is downloading a
significant database replication update.  The GW oes down.  The Client
connection is still viable.  If the GW goes down and I am the host I do
not want to depend on the GW being smart enough to receive my ESP packet
and negotiate a new tunnel, especially when QCD might let me (the host)
initiate a new tunnel.  It really does not matter if the Host could have
done this initial negotiation.  It just to be able to reconstitute the SA.

When the GW goes down the host still has the IKE and Child SAs, and in
many cases it should be able to renegotiate them just as though it were
reauthenticating.

It seems unlikely to me that every GW behaves as Tero suggests here.  In
case that do not behave as Tero suggest QCD will allow me to drive a faster

recovery.

I think allowing both the initiator and responder to be token makers
actually keeps the protocol simpler.  From an implementation perspective
I'd prefer to take advantage of QCD as a rather than rely on the fact that
every gateway behaves as Tero suggests.  Using QCD seems like a simpler
and safer approach.

>> In a previous append Tero said:
>> >As I explained that if both ends can initiate the creation of the IKE
>> >SA, then QCD is not needed as both end can simply recreate the IKE SA
>> >immediately (with INITIAL_CONTACT notify) when they are up and running
>> >(or when they receive first unknown ESP packet from the configured
>> >peer). This is simple and already specified by the IKEv2, so no new
>> >code is needed.
>>
>> I certainly would not advise creating an IKE_SA based on the receipt of
>> an unknown ESP packet from a configured peer.  If the ESP packet is
>> unknown then it is not authenticated and could have come from anywhere.
>
>Yes it is not authenticated, but you do have limited number of
>configured IP-addresses in your configuration file, which means that
>attacker can only set up IKE SA for exactly those hosts, not any
>other, and as you only create the IKE SA if you do not have any, then
>only thing attacker can cause is you to create the IKE SA even when
>you do not yet have traffic to go that way.

I'm not so sure that having a limited number of configured IP addresses in
the configuration file equates to having a small number of address.  It is
also likely that one could easily determine the range of valid addresses.

>
>> Prior to QCD, if the initiator of the initial IKE_SA reboots and then
>> receives a packet with an invalid ESP SPI from the responder the
>> initiator would send an INVALID_SPI notify to the responder.
>
>As I said, in our case we do check our configuration and if the
>invalid ESP packet has IP-address which matches a known peer in the
>configuration file, our implementation do set up the IKE SA for the
>peer and do send Child SA delete for the ESP SPI to clean up the
>state.

But how do you authenticate that address?  Are you saying that if I
find an addresses in your config file that I can sit there all day
sending you bogus ESP packets and watch you initiate IKE_SAs?  I must
be missing something here.


Dave Wierbowski

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00

[David Wierbowski]

Tero writes:
>I do not consider very open protocols which allow all kind of things
>"just for fun" and "in case we someday get scenario which can use it"
>as good thing.

I do not think we are allowing the initiator and responder to
be both a taker and a maker just for fun.  There are cases where
either side can initiate and it makes sense in those cases.

In a previous append Tero said:

>As I explained that if both ends can initiate the creation of the IKE
>SA, then QCD is not needed as both end can simply recreate the IKE SA
>immediately (with INITIAL_CONTACT notify) when they are up and running
>(or when they receive first unknown ESP packet from the configured
>peer). This is simple and already specified by the IKEv2, so no new
>code is needed.

I certainly would not advise creating an IKE_SA based on the receipt of
an unknown ESP packet from a configured peer.  If the ESP packet is
unknown then it is not authenticated and could have come from anywhere.

Prior to QCD, if the initiator of the initial IKE_SA reboots and then
receives a packet with an invalid ESP SPI from the responder the
initiator would send an INVALID_SPI notify to the responder.  The
responder would then start dead peer detection.  It's Tero's belief that
this should use a shorten retransmission timer.  Section 7.4 of the QCD
draft explains why using a shortened retransmission timer is not wise,
but let's assume one does use a shorten timer.  That shortened timer
introduces a delay that QCD eliminates.

Tero desires QCD to limit the role of taker to the initiator.  He seems
to expect that the initiator would not only retain a mapping of received
tokens to IKE_SAs, but also a mapping of ESP SAs to IKE_SAs.  When the
initiator gets a packet with an invalid SPI after a reboot he wants
the initiator create a new IKE_SA.  Actually, I think he wants to do
this without saving any state (i.e. without QCD).

Section 9.2 of QCD indicates that a implementation MAY maintain such
a mapping.  As such QCD does not require such a mapping.  QCD states
that in the case where such a mapping is maintained that the initiator
should respond with both an INVALID_SPI notification and a QCD_TOKEN
notification.  The reason for this action is that the initiator should
not start an IKE_SA negotiation based on an unauthenticated packet.

As such, it makes sense to allow the initiator and responder to be both
a taker and a maker in environments where either side is capable of
initiating the IKE_SA negotiation.

Dave Wierbowski





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00

[David Wierbowski]

Tero writes:
>Paul Hoffman writes:
>> >True, we need some other term for it. Something like the original
>> >IKE_SA_INIT initiator or the party initiating the initial connection
>> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
>> >exchanges and rekeys can only be sent by the peer who originally sent
>> >them in the IKE_AUTH, and in IKE_AUTH limit the QCD_TOKEN to the
>> >responder.
>>
>> Is this added complexity really needed? It sounds like a dangerous
>> addition. Please be sure the value is actually worth the risk.
>
>I am suggesting simplyfying the protocol, not adding complexity. It
>might add some text to the specification, but reduce code from the
>implementation, as then implementation is always either token maker or
>taker, never both.

I disagree with this "simplification."  Tero's logic is that this does make
sense in some cases (e.g. his case), so let's disallow it.  As Scott Moonen
pointed out, there are cases where it is perfectly valid to expect either
endpoint to send the next packet and cases where it makes sense that either
endpoint can initiate the creation of an IKE SA.  I see no reason to
restrict who can be a token maker and a token taker.  IMHO, Adding this
restriction just reduces the potential effectiveness of the solution.

Dave Wierbowski

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Failure detection proposals, stage 2

[David Wierbowski]

I also prefer  the QCD draft over the SIR draft.  My reasons are similar to
Scott's.  I feel the method in QCD is sufficient and the SIR method is
overly complex for the problem at hand.  I think SIR would be bigger to
implement and more error prone than QCD.  In short I think the SIR method
is a much bigger stick than needed.

Dave Wierbowski


z/OS Comm Server Developer

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






From:   Scott C Moonen/Raleigh/i...@ibmus
To: Yaron Sheffer 
Cc: IPsecme WG , ipsec-boun...@ietf.org
Date:   08/13/2010 03:10 PM
Subject:Re: [IPsec] Failure detection proposals, stage 2
Sent by:ipsec-boun...@ietf.org



I've looked over the two drafts. My summary impression is that I prefer
QCD, albeit for subjective reasons. It is less complicated and therefore
simpler to implement and test. I think I would have a higher degree of
confidence in planning it for our implementation, and I suspect it would
see more quick and widespread use.

Some comments/questions for the individual drafts:

QCD:
(1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request
message for rekeying the IKE SA?
(2) The draft (perhaps in the section 5 intro) should emphasize that the
tokens MUST be produced in such a way that different IKE SPI pairs are
unlikely to share the same token value.

Recovery:
(1) The draft needs to specify how the IKE message header bits are expected
to be set for the various flows.
(2) The draft should explicitly acknowledge cases where it is (with good
reason) breaking specific MUST NOT statements in ikev2bis (e.g., a couple
of cases of "MUST NOT respond").
(3) I dislike the MITM weakness but I understand that this is not the most
attractive fruit for a MITM.
(4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs" is
preferred to "SA's").


Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

(Embedded image moved to file: pic56651.gif)Inactive hide details for Yaron
Sheffer ---08/10/2010 06:20:17 AM---OK, Paul and I are finally convinced
that we have sufficienYaron Sheffer ---08/10/2010 06:20:17 AM---OK, Paul
and I are finally convinced that we have sufficient WG interest in solving
this problem. N

From: Yaron Sheffer 
To: IPsecme WG 
Date: 08/10/2010 06:20 AM
Subject: [IPsec] Failure detection proposals, stage 2
Sent by: ipsec-boun...@ietf.org



OK, Paul and I are finally convinced that we have sufficient WG interest
in solving this problem. Now, I'd like to ask the people who have
responded (as well as others) to read the two drafts, and to tell us why
they prefer the one over the other.

Quoting myself: "If you speak up, we will expect you to contribute to
the selection of the preferred document".

Please respond with comments to the drafts and/or a comparison within
the next week, i.e. by August 17.

Thanks,
Yaron

> From: Yaron Sheffer
> To: IPsecme WG
> Date: 08/04/2010 04:48 PM
> Subject: [IPsec] Failure detection proposals
> Sent by: ipsec-boun...@ietf.org
>
>
>
> In the Maastricht meeting there was just a tiny bit of interest in the
> failure detection idea (reminder: the goal is to ensure that one peer
> discovers that the other IKE peer has restarted, within a short time
> duration, milliseconds instead of minutes). But we didn't see enough
> interest to justify having this as a WG item. So, one last time: if you
> think this is a worthwhile idea, regardless of the proposals on the
> table, please say so publicly. If you speak up, we will expect you to
> contribute to the selection of the preferred document.
>
> If this is of no interest, fine. But if it is an important problem to
> solve and we don't take it on, we could end up with competing non-WG
> proposals. Which would be far from ideal.
>
> Thanks,
> Yaron
>
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Paul Hoffman
> Sent: Wednesday, July 07, 2010 8:03 PM
> To: IPsecme WG
> Subject: [IPsec] NUDGE: Starting discussion of failure detection
proposals
>
> [[ This topic generated a fair amount of discussion in the past; are
> folks still interested? ]]
>
> Greetings again. The WG has one item on our charter that we have barely
> discussed, namely failure detection. The charter item says that the work
> item is:
>
>> - A standards-track IKEv2 extension that allows an IKE peer to quickly
and
> securely detect that its opposite peer, while currently reachable, has
lost
> its IKEv2/IPsec state. Changes to how the peers recover from this
situation
> are beyond the scope of this work item, as is improving the detection of
an
> unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
> draft-detienne-ikev2-recovery-03 can be used as starting points.
>
> I gave a brief presentation on failure detection at the last IETF
> meeting in Anaheim. The slides are at
> , and the
> followi

Re: [IPsec] Failure detection proposals

[David Wierbowski]

I agree with Scott and I am also willing to participate in discussion of
the alternatives.

Dave Wierbowski





From:   Scott C Moonen/Raleigh/i...@ibmus
To: Yaron Sheffer 
Cc: IPsecme WG , ipsec-boun...@ietf.org
Date:   08/05/2010 09:33 AM
Subject:Re: [IPsec] Failure detection proposals
Sent by:ipsec-boun...@ietf.org



I think this is an important problem to solve and I'm willing to
participate in discussion of the alternatives,

Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

(Embedded image moved to file: pic03142.gif)Inactive hide details for Yaron
Sheffer ---08/04/2010 04:48:45 PM---In the Maastricht meeting there was
just a tiny bit of inteYaron Sheffer ---08/04/2010 04:48:45 PM---In the
Maastricht meeting there was just a tiny bit of interest in the failure
detection idea (remi

From: Yaron Sheffer 
To: IPsecme WG 
Date: 08/04/2010 04:48 PM
Subject: [IPsec] Failure detection proposals
Sent by: ipsec-boun...@ietf.org



In the Maastricht meeting there was just a tiny bit of interest in the
failure detection idea (reminder: the goal is to ensure that one peer
discovers that the other IKE peer has restarted, within a short time
duration, milliseconds instead of minutes). But we didn't see enough
interest to justify having this as a WG item. So, one last time: if you
think this is a worthwhile idea, regardless of the proposals on the
table, please say so publicly. If you speak up, we will expect you to
contribute to the selection of the preferred document.

If this is of no interest, fine. But if it is an important problem to
solve and we don't take it on, we could end up with competing non-WG
proposals. Which would be far from ideal.

Thanks,
Yaron

-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals

[[ This topic generated a fair amount of discussion in the past; are
folks still interested? ]]

Greetings again. The WG has one item on our charter that we have barely
discussed, namely failure detection. The charter item says that the work
item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quickly and
securely detect that its opposite peer, while currently reachable, has lost
its IKEv2/IPsec state. Changes to how the peers recover from this situation
are beyond the scope of this work item, as is improving the detection of an
unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
draft-detienne-ikev2-recovery-03 can be used as starting points.

I gave a brief presentation on failure detection at the last IETF
meeting in Anaheim. The slides are at
, and the
following is directly derived from them.

The basic problem being covered by the new extension is:
-  Alice and Bob have SAs up and ESP traffic is flowing, but then Bob
crashes
-  Alice keeps sending ESP to Bob
-  When Bob finally comes back up, he replies to Alice's ESP with
INVALID_SPI notifications
-  Alice starts sending IKE liveness checks until she is "sure" that the
INVALID_SPI responses are not a DoS attack; this could be "several minutes"
-  Then Alice rekeys

Some other problem cases include:
-  Bob has two gateways in some failover architecture. One gateway goes
down, the other gateway detects this and wants to tell Alice to rekey
-  Bob has a bunch of gateways in some load-balancing or cluster
architecture. One gateway is taken down on purpose, and the system wants
to tell Alice to rekey
-  Protocol robustness:  Bob's gateway loses the SA without going down

Our primary goal is that, as soon as Bob starts sending INVALID_SPI
responses to Alice's ESP traffic, Bob and Alice should be able to
quickly determine that this is not an attack and therefore they probably
want to rekey right away. Note that if Bob and Alice are also using
session resumption, they can use that instead of rekeying; however, in
the discussion here, we always use "rekey" to mean "rekey or, if
appropriate, resume". The proposed extension does not include the actual
rekeying, just the context for them to do it now.

The WG has seen two proposed solutions, QCD and SIR. The following are
brief summaries of the two proposals.

In QCD (), Bob gives Alice
a secret token in the AUTH exchange, and then puts the token in his
INVALID_SPI response as a way to say "this SPI is gone". Bob must
remember his tokens across reboots, or derive tokens from a master token
that he memorizes across reboots, and Alice must remember the token (or
a hash of it) for each SA.

In SIR
(), Alice
sends a new Check_SPI query with a stateless cookie, essentially asking
"do you really not know about this
SPI?"; Bob responds b

Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski]

>I do not want the current text to be removed just because some people
>think it is not clear as for me it is clear enough and it is something
>that needs to be mentioned, and I have not seen better text to replace
>it.

What about:

If any Child SA fails in such way that a delete notification cannot be
sent, then the corresponding IKE SA and all its associated Child SAs
MUST be deleted.  If the IKE SA fails without being able to send a
delete message, then all Child SAs created by the IKE SA MUST be silently
deleted.



Dave Wierbowski




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski]

>Do you think it is legal to create a system where one Child SA can
>fail in such way that IKE SA cannot send delete notification?

I do not think a robust IKE implementation would allow this.

>
>The current text says it is not legal, but your replacement text
>allows it.

The current bis text is:
   If a system creates Child SAs that can fail independently from one
   another without the associated IKE SA being able to send a delete
   message, then the system MUST negotiate such Child SAs using separate
   IKE SAs.

This text also does not prevent the above.  It just says how the
children can be created.  It says nothing about what happens when
they fail.

>
>I do not think such setup should be allowed. I.e. if any of the Child
>SAs or the associated IKE SA fail, in such way that delete
>notification cannot be sent, then all the Child SAs AND the IKE SA
>needs to be destroyed.

Then say that.  Say if a Child SA fails and a delete notification
cannot be sent then the IKE SA must be deleted.  Personally I think
you change how you interpret the sentence each time you respond which
just echoes Paul's original point, that the text is not clear.

Dave Wierbowski





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski]

>> I don't think we need to mandate how a particular situation should be
>> handled.  That is up to the implementer.  The implementer just needs to
>> know that there is a rule that states the it is not for some child SAs
>> stay up when the IKE_SA disappears.  I think the existing text could be
>> deleted.
>
>But the existing text is the text which gives this rule or at least
>try to. I.e. it tries to say that if implementation cannot guarantee
>that all Child SAs and IKE SAs stay up together, then you cannot
>negotiate all those Child SAs using the same IKE SA.
>
>This same can partially be seen from the:
>
>  Receipt of a fresh cryptographically protected message on an IKE SA
>  or any of its Child SAs ensures liveness of the IKE SA and all of
>  its Child SAs.
>
>text, but some people might be missing the point that ALL Child SAs
>and corresponding IKE SAs must stay up together.

What I do not like about the text is that it is a rule related to the
life of the Child SAs.  I think it would be clearer to tie the rule
to the termination of the IKE SA.  For example I think replacing the
text with some thing like the following is more straight forward:

If an IKE SA fails without being able to send a delete
message, then all Child SAs created by the IKE SA MUST be silently
deleted.

On the other hand I am not saying the existing text must be removed.
I'm just saying that I think it could be removed.


Dave Wierbowski


z/OS Comm Server Developer

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski]

>I think we need to mandate that logic you explained there to the RFC.
>The text there does that. It says that you need to keep Child SAs and
>IKE SAs connected, and either all of them work, or none of them work
>(or you might also get delete notifications for those which failed,
>provided the IKE SA stays up).
>
>What is not allowed that some of the Child SAs stay up, but the IKE SA
>does not (i.e. no delete notifications). And this from the remote
>point of view, i.e. if you maintain internal bookeeping and destroy
>the Child SA when one security processor fails, that is fine, and from
>the remote point of view all Child SAs and IKE SA got destroyed.

I don't think we need to mandate how a particular situation should be
handled.  That is up to the implementer.  The implementer just needs to
know that there is a rule that states the it is not for some child SAs
stay up when the IKE_SA disappears.  I think the existing text could be
deleted.

Dave Wierbowski


z/OS Comm Server Developer

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Another round of IKEv2-bis issues

[David Wierbowski]

>Yoav Nir writes:
>> Issue #181 - Section 2.4 unclear on Child SA failing
>> 
>> Section 2.4 says "If Child SAs can fail independently from one
>> another without the associated IKE SA being able to send a delete
>> message, then they MUST be negotiated by separate IKE SAs". It is
>> not clear what this means. Does it apply to implementations? If so,
>> how can an implementation know whether or not the first clause is
>> true?
>>
>> I propose removing the sentence, or greatly clarifying it.
>>
>> Tero and Dave commented. Dave proposed alternative text, replacing
>> "they" with "each set of Child SAs":
>>
>> If sets of Child SAs can fail independently from one another without
>> the associated IKE SA being able to send a delete message, then each
>> set of Child SAs MUST be negotiated by separate IKE SAs.
>>
>> But I think this misses Sean's point, that while an implementation
>> might be able to know whether child SAs fail independently in
>> itself, it has no way of knowing this about the peer.
>
>Why should it know it about the peer? If the other end used same IKE
>SA to negotiate the Child SAs, then those Child SAs cannot fail
>independently.
>
>This case is only for the local implementors, it does not have any
>protocol implications, except that other end can assume that if Child
>SA A, and Child SA B are negotiated using same IKE SA C, then if A
>works, that means that B also works (or the Child SA is deleted using
>IKE SA C).
>
>The current text does not say anything what happens if the host Z
>tries to create Child SA A and Child SA B using IKE SA C, and host X
>notices that it cannot guarantee, that they cannot fail independently.
>Most likely host X will then return error, but most likely it can also
>make Child SA A and B so that they cannot fail independently, i.e.
>allocate them from the same security processor.
>
>I.e. if we make example where we have host A, having multiple security
>processors F, G, and H. Each of those security processors is able to
>run full IPsec, including multiple IKE SAs and Child SAs. Each of
>those security processors is separate, i.e. SAs are not shared between
>them, thus each IKE SA and Child SA is on only one of them. Also in
>this example we assume that one of those security processors can fail
>independently from others, i.e. even if one of them crashes, or looses
>state, the others can stay up. The device itself will then of course
>need some kind of internal "switch" inside, which will "route" IKE and
>Child SA packets to corresponding security processor.
>
>Now when host A is initiating negotiations it needs to make sure that
>the Child SAs and the corrseponding IKE SA are on the same security
>processor so if one of them fail, then all of them fail.
>
>If this is not true, then host B reciving packets from host A using
>child SA which happened to be on the other security processor than the
>IKE SA of that child SA, still thinks the host A is up and running,
>even when the IKE SA is already dead.

What is wrong with using a valid child SA?  If you are claiming
the child SA is not valid because it's IKE SA on host A no longer
exists then I'll agree.  When host A lost the IKE SA because the
security processor failed it should have cleaned up any SAs created
by the IKE SA.  That does not mean all SAs created by the IKE SA need
be on the same security processor.  That's just your rule and how you
decided to handle the situation.  You could have kept knowledge of
this relationship outside of the security processor.  I see no reason
to dictate how to handle this situation in the RFC.

>This means that host B will
>never start DPD, as it is seeing valid packets from host A coming in,
>thus it will never notice that other Child SAs and the IKE SA on the
>other security processor are dead, and will happily send data to them
>without trying to recover.

Well if host A did not properly cleanup up all child SAs I agree this
could happen, but so what?  Everyone is happy.  Data is being
exchanged as per the child SA.  If host A did kill the child SA then
dead peer detection would kick in as desired.

It's probably more of an issue if the security processor
containing a child SA died while the IKE SA was
in another security processor, but I contend that in this scenario an
implementation could be smart enough to know what child SAs are
associated with each security processor and properly clean up.  In
this case it would even be able to send a delete.

>
>As the crash recovery is done on the IKE SA bases, and the crash
>recovery assumes that if any of the Child SAs on the IKE SA is alive,
>then the IKE SA is also alive, it is important that Child SAs and IKE
>SA cannot fail independently.

It's all a matter of bookkeeping.  If they can fail separately you just
need to keep track of what needs to be cleaned up when a failure occurs.
The method you suggest is perhaps a good one and the easiest, but
it is not the only one.

Re: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing

[David Wierbowski]

>> I propose removing the sentence, or greatly clarifying it.
>
> For me the current text is very clear, and I do not see how we can
> clarify greatly. This issue usually only affects implementations where
> there are multiple subsystems which can fail independently from each
> other. If the only failure model is that the whole device
> crashed/rebooted etc then this text does not apply, as all IPsec SAs
> (and IKE SAs) disappear at the same time.

I disagree with the Tero's comment statement that the text is very clear,
I've never understood exactly what the statement  meant until I read the
example that Tero provided.  Based on that I would at least recommend
changing the text as follows:

If sets of Child SAs can fail independently from one
another without the associated IKE SA being able to send a delete
message, then each set of Child SAs MUST be negotiated by separate IKE SAs.

It might even be approbate to add Tero's example:

For example if sets of IPsec SAs are associated with different crypto
chips, and
each chip can fail independently causing all IPsec SAs associated with the
chip
to disappear then each set of IPsec SAs should be negotiated with a
different IKE SA.

Dave Wierbowski




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #176: What to do with a proposal of NONE

[David Wierbowski]

I agree.





 
  From:   Paul Hoffman   
 

 
  To: Tero Kivinen  
 

 
  Cc: IPsecme WG , Pasi Eronen   
 

 
  Date:   03/08/2010 10:22 AM   
 

 
  Subject:Re: [IPsec] Issue #176: What to do with a proposal of NONE
 

 
  Sent by:ipsec-boun...@ietf.org
 

 





At 5:10 PM +0200 3/8/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> 
>>
>> Pasi says:
>>
>> Section 3.3.6 says "If one of the proposals offered is for the
>> Diffie-Hellman group of NONE, the responder MUST ignore the
>> initiator's KE payload and omit the KE payload from the response."
>>
>> This seems wrong: it seems to say that if the initiator proposes DH
group NONE, the responder must select it.
>>
>> However, negotiation of DH groups and KE payload is already well
>> described in Sections 1.2 and 1.3 (paragraphs mentioning
>> INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is
>> completely redundant. Thus, I'd propose just deleting the whole
>> paragraph.
>>
>> Paul says:
>>
>> That whole paragraph has been there since -00. Only the last
>> sentence was added in -03 almost a year ago. It was added to fix
>> , but I can
>> easily believe that fix was not correct. However, sections 1.2 and
>> 1.3 don't address the issue in the sentence quoted.
>
>The last sentence is the one that is misleading. All of the rest of
>the paragraph is just repeation of the text from elsewhere.
>
>The last sentence should be saying:
>
>  If one of the proposals offered is for the
>   Diffie-Hellman group of NONE, and the responder selects that
>   Diffie-Hellman group, then it MUST ignore the initiator's KE
>   payload and omit the KE payload from the response.
>
>I.e. the MUST ignore, and omit the KE payload is only applicable if
>responder actually selects the Diffie-Hellman group NONE.

That makes good sense to me, and seems like less of a change to 4306 than
the current wording. Do others agree?

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Issue #172: Config payload text in Section 4

[David Wierbowski]

 Section 4 of IKEv2bis states:

A minimal IPv4 responder implementation will ignore the contents of
the CP payload except to determine that it includes an
INTERNAL_IP4_ADDRESS attribute and will respond with the address and
other related attributes regardless of whether the initiator
requested them.

A minimal IPv4 initiator will generate a CP payload containing only
an INTERNAL_IP4_ADDRESS attribute and will parse the response
ignoring attributes it does not know how to use.

 The terms "minimal IPv4 responder implementation" and "minimal IPv4
 initiator" are confusing and misleading.  This text is a  restatement of
 the previous paragraph.

 This text should be removed or reworded to describe IPv6 implementation
 behavior to the same extent. It should also be reworded to clarify what
 is meant by "minimal implementation." Since responding to a config payload
 is optional, a "minimal implementation" in this context must refer to an
 implementation that minimally supports responding to a config payload.

 The recommendation is to remove this paragraph.  It adds no new
 information and adds no clarify to the text in the previous paragraph.


Dave Wierbowski


z/OS Comm Server Developer

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David Wierbowski]

>>I agree with the wording Tero has provided and I think that is
>>what the intent of the original text was.
>
>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


z/OS Comm Server Developer

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David Wierbowski]

>At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>Paul Hoffman writes:
>>> 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.
>>>
>>> [[ 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.
>
>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.

>
>>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).
>
>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.

>
>--Paul Hoffman, Director
>--VPN Consortium

Dave Wierbowski


z/OS Comm Server Developer

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Config payload text in Section 4

[David Wierbowski]

Section 4 of IKEv2bis (and RFC 4306) states:

   IKEv2 is designed to permit minimal implementations that can
   interoperate with all compliant implementations.  There are a series
   of optional features that can easily be ignored by a particular
   implementation if it does not support that feature.  Those features
   include:

   o  Ability to negotiate SAs through a NAT and tunnel the resulting
  ESP SA over UDP.

   o  Ability to request (and respond to a request for) a temporary IP
  address on the remote end of a tunnel.

A little further down Section 4 also states:

   Implementations are not required to support requesting temporary IP
   addresses or responding to such requests.

Finally Section 4 also states:

   A minimal IPv4 responder implementation will ignore the contents of
   the CP payload except to determine that it includes an
   INTERNAL_IP4_ADDRESS attribute and will respond with the address and
   other related attributes regardless of whether the initiator
   requested them.

   A minimal IPv4 initiator will generate a CP payload containing only
   an INTERNAL_IP4_ADDRESS attribute and will parse the response
   ignoring attributes it does not know how to use.

By reading all the text in Section 4 it is seems that  "minimal IPv4
responder implementation" means an implementation that minimally supports
responding to a config payload request and that "minimal IPv4 initiator"
means an implementation that minimally supports requesting a temporary IP
address.  Unfortunately, the terms "minimal IPv4 responder implementation"
and "minimal IPv4 initiator" alone are somewhat ambiguous and can be
interpreted as contradiction to the first two statements I cited above.  I
suggest changing the text in the last two paragraphs I cited to:

   An implementation that minimally supports responding to a request for a
   temporary IP address will ignore the contents
   of the CP payload except to determine that it includes an
   INTERNAL_IP4_ADDRESS attribute and will respond with the address and
   other related attributes regardless of whether the initiator
   requested them.

   An implementation that minimally supports requesting a temporary IP
address
   will generate a CP payload containing only
   an INTERNAL_IP4_ADDRESS attribute and will parse the response
   ignoring attributes it does not know how to use.



Dave Wierbowski




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes?

[David Wierbowski]

I'm not sure I'm going to buy that garage door opener if I have to wait for
dead peer detection before I can open or close it again :>).

Dave Wierbowski








  From:   Tero Kivinen  



  To: Yoav Nir 



  Cc: IPsecme WG , Paul Hoffman  



  Date:   12/16/2009 05:55 AM   



  Subject:Re: [IPsec] Issue #128: Can implementations not reply fully to 
Deletes?   


  Sent by:ipsec-boun...@ietf.org








Yoav Nir writes:
> Section 1.4.1 also says:
>
> "A node MAY refuse to accept incoming data on half-closed
>connections but MUST NOT unilaterally close them and reuse the SPIs."
>
> So if your peer is only responding with empty INFORMATIONAL
> responses to your deletes, you're going to accumulate more and more
> stale inbound SAs.

In which case you follow the text in 1.4.1 which says:

   If connection state becomes sufficiently messed up, a node MAY close
   the IKE SA; doing so will implicitly close all SAs negotiated under
   it.  It can then rebuild the SAs it needs on a clean base under a new
   IKE SA.  The response to a request that deletes the IKE SA is an
   empty Informational response.

and that will fix the situation with minimal implementation. Also with
minimal implementation you cannot really get more and more stale
inbound SAs, as if implementation is so small it does not support
Delete notifications, it most likely doesnot support more than one
Child SA, i.e. it does not support CREATE_CHILD_SA (it will always
reply with NO_ADDITIONAL_SAS to that), thus at most you get one extra
SA. And as other end didn't understand the delete, it is not stale, as
it will be working half-closed SAs, it is outbound SA for you and if
you encrypt data and send it to the minimal implementation it will
still decrypt, and process that packet. It will might even send reply
back to your already closed inbound SA, but you will drop that as you
have already deleted that half.

> One of these statements has to go.

Not really. Note, that I would expect all normal versions of the IPsec
to support both CREATE_CHILD_SA and delete notifications, but we are
talking now about the minimal requirements.

I.e. if you have your battery powered garage door opener, who knows
IKEv2 just enough to do IKE_SA_INIT (with exactly one set of crypto
algorithms), IKE_AUTH (with preshared key and with one set of crypto
algorithms and fixed traffic selectors). It only supports this exactly
one Child SA, which it uses to send message saying "Open or Close the
garage door" and after 30 seconds if no more buttons is pressed it
will shutdown.

As it does not support CREATE_CHILD_SA or INFORMATIONAL in any other
way than sending NO_ADDITIONAL_SAS or empty reply back, it does not
know how to process delete payloads at all. It even does not know how
to delete the IKE SA, but that does not matter as it automatically
goes away when it automatically turns itself off.

It expects that your home area network server which acted as responder
to its IPsec connection is smart enough to start DPD later and when
garage door opener does not reply it will also delete the IKE SA from
the server side.

This kind of minimal implementations are not meant to be used in
normal operations.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #130: Do we need to bump the minor version number?

[David Wierbowski]

I think it is reasonable to expect that an IKEv2 bis implementation would
use an IF statement to control sending the new Notify types.  If the minor
number was changed an implementation could check the minor version and send
the new notify types when the minor version was 1 and send the notify types
recommended in RFC 4718 if the minor number was 0.  That is what my
implementation plans to do if the minor version number is bumped.

I'm not sure I agree with Tero that an implementation getting an unknown
TEMPORARY_FAILURE notify would always take the same action that it would if
it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718.

Dave Wierbowski




  From:   Richard Graveman



  To: Tero Kivinen  



  Cc: IPsecme WG , Paul Hoffman  



  Date:   12/17/2009 07:41 AM   



  Subject:Re: [IPsec] Issue #130: Do we need to bump the minor version 
number?  


  Sent by:ipsec-boun...@ietf.org








I think the criterion should be:

Would a reasonable and correct implementation need to have an IF
statement, e.g., if(minor_number == 1) ...

I do not not think the criterion should be whether bumping the number
breaks older implementations.

>From the discussion, leaving the number alone seems fine.

Richard

On Thu, Dec 17, 2009 at 7:20 AM, Tero Kivinen  wrote:
> Yaron Sheffer writes:
>> Or else, we could remove the sentence "For example, it might
>> indicate the ability to process a newly defined notification
>> message."
>
> That is example what changing minor number might mean. All current
> conforming implementations already know how to process our newly
> defined error notifications (they assume exchange failed), thus there
> is no need to update minor number, as there is no new ability needed
> for implementations to process those notifications.
>
> There is no reason to change that text. It does not require us to do
> something, it is just example.
>
>> I thinking bumping the minor version number would be
>> extremely risky. We know that everybody can ignore unknown
>> notifications. We don't know that everybody can deal correctly with
>> version number, simply because this has been tested less frequently.
>
> Agree on that.
> --
> kivi...@iki.fi
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!)

[David Wierbowski]

Paul,

I haven't matched Scott's efforts, but I do have some comments:

Comment  #1:

Section 1.2 (The Initial Exchanges) has the following sentence, which was
also in RFC 4306.

   Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ], indicate that optionally a certificate request
   payload can be included.

This wording seems awkward to me.  I suggest changing "indicate" to
"indicating" as below:

   Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ], indicating that optionally a certificate request
   payload can be included.

Comment # 2:

Section 1.7 (Differences Between RFC 4306 and This Document) states:

   The protocol described in this document retains the same major
   version number (2) and minor version number (0) as was used in RFC
   4306.  That is, the version number is *not* changed from RFC 4306.

Section 2.5 (Version Numbers and Forward Compatibility) states

   The minor
   version number indicates new capabilities, and MUST be ignored by a
   node with a smaller minor version number, but used for informational
   purposes by the node with the larger minor version number.  For
   example, it might indicate the ability to process a newly defined
   notification message.  The node with the larger minor version number
   would simply note that its correspondent would not be able to
   understand that message and therefore would not send it.

New notifies have been added to the bis draft.   Is a bump in the minor
number warranted?  Is there a down side to bumping the minor number?

Comment # 3:

Section 2.8.1 Simultaneous Child SA rekeying states:

   To B, it looks like A is trying to rekey an SA that no longer exists;
   thus, B responds to the request with something non-fatal such as
   NO_PROPOSAL_CHOSEN.

<--  send resp1: N(NO_PROPOSAL_CHOSEN)
   recv resp1 <--

   When A receives this error, it already knows there was simultaneous
   rekeying, so it can ignore the error message.

Section 2.25.1 Exchange Collisions states:

   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.

This seems to be inconsistent.  I suspect that the text in section 2.8.1
should be updated to show CHILD_SA_NOT_FOUND sent instead of
NO_PROPOSAL_CHOSEN.

Comment #4:

Section 2.8.2 Simultaneous IKE SA Rekeying states:

   If only one peer detects a simultaneous rekey, redundant SAs
   are not created.  In this case, when the peer that did not notice the
   simultaneous rekey gets the request to rekey the IKE SA that it has
   already successfully rekeyed, it MUST return TEMPORARY_FAILURE
   because it is an IKE SA that it is currently trying to close (whether
   or not it has already sent the delete notification for the SA).

Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:

   If a peer receives a request to close an IKE SA that it is
   currently trying to close, it SHOULD reply as usual, and forget about
   its own close request.

Based on the text in Section 2.25.2 it seems that perhaps the MUST in
Section 2.8.2 is really a SHOULD.


Comment #5

In section Section 2.8.2 Simultaneous IKE SA Rekeying I suggest we start a
new paragraph at the sentence:

   If only one peer detects a simultaneous rekey, redundant SAs
   are not created.


Comment #6

Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:
   If
   the peer that did notice the simultaneous rekey gets the delete
   request from the other peer for the old IKE SA, it knows that the
   other peer did not detect the simultaneous rekey, and the first peer
   can forget its own rekey attempt.

   However, there is a twist to the other case where one rekeying
   finishes first:

   Host A  Host B
   ---
   send req1:
SA(..,SPIa1,..),Ni1,.. -->
 <-- send req2: SA(..,SPIb1,..),Ni2,..
 --> recv req1
 <-- send resp1: SA(..,SPIb2,..),Nr2,..
   recv resp1 <--
   send req3: D() -->
 --> recv req3

   At this point, host B sees a request to close the IKE_SA.  There's
   not much more to do than to reply as usual.  However, at this point
   host B should stop retransmitting req2, since once host A receives
   resp3, it will delete all the state associated with the old IKE_SA
   and will not be able to reply to it.

 <-- send resp3: ()

I suggest  the sentence, "However, there is a twist to the other case where
one rekeying finishes first: " be deleted.  The sample flow that follows it
is just a more detailed description of the sentence that proceeds it.  The
sentence made sense at

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[David Wierbowski]

>> I don't agree with you. Remember, when IKEv2 was being developed,
>> one of the motivations for single self-contained document was complaint
>> from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
>> was very inconvinient and provoked confusions that led to
interoperability
>> problems. Now you suggest to make IKEv2 not self-contained again.
>> Of course, I understand that IANA registry is not another RFC, but
>> I still prefer single self-contained document for core protocol.
>> If you need extensions - go to IANA and look for added numbers,
>> but core protocol must be implementable reading as few sources,
>> as possible, preferrably one.
>
>I completely agree on that.

I also agree with Valery and Tero.

Dave Wierbowski



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #120: CA indication with cert req - allowed types

[David Wierbowski]

> So the text most likely should say that "For other values the
> certificate authority field contents is not defined, and can be
> anything (or empty) until specifications that specify their contents
> is published."
I do not think they can be anything.  I think they need to be empty until
specifications that specify their contents are published.

Dave Wierbowski


z/OS Comm Server Developer

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #119: Which certificate types can be mixed in one exchange?

[David Wierbowski]

> Should be added to Sec. 3.6, probably as a new subsection.


> One Hash & URL (H&U) bundle only. Or...


> One Raw RSA key, or...


> One or more cert payloads of either type 4 or H&U (type 12)


I think there are cases where it makes sense to send any combination of
types 7, 12, and 13.  I do not think we should restrict which of those
certificate types can be mixed in one exchange.


>Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of
the above, except for Raw RSA.
I thought  sending CRLs inline.was strongly discouraged, but I agree that
if an implementation sends them that it would be logical to include one or
more CRLs.

Are we planning on updating the list of certificate encoding types to
include type 14 (OSCP content)?  If yes then I do not see that in the
current bis draft.

Dave Wierbowski


z/OS Comm Server Developer

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #120: CA indication with cert req - allowed types

[David Wierbowski]

> Sec. 3.7 has:


  > The contents of the "Certification Authority" field are defined
  only for X.509 certificates, which are types 4, 10, 12, and 13. >
  Other values SHOULD NOT be used until standards-track specifications
  that specify their use are published.


> This excludes certificate requests of type 7, i.e. for CRLs. For
requesting a specific CRL type 7 would make sense, in particular in > chain
situations. Should we add it to the list of allowed types here?


RFC 4945 states that implementations SHOULD NOT send CERTREQs for types 7
and 8.  If they are sent then an implementation MUST NOT require the
recipient to respond and the recipient MAY ignore the request.  Given that
I don't expect that it is common that implementations send CERTREQs with
type 7 or 8 to begin with.  If they do I agree with Tero that an empty
certificate authority field is probably sufficient.


OTOH, I would not be opposed to adding RFC 4945's "SHOULD NOT send CERTREQs
for type 7 and 8" statement here.


> OTOH, this allows type 10, which is unspecified and should be removed.




Dave Wierbowski


z/OS Comm Server Developer

 Phone:
Tie line:   620-4055
External:  607-429-4055
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #22 Simultaneous IKE SA rekey text

[David Wierbowski]

Tero Wrote:
> RFC4718 is informational and tried to clarify things which are not
> clear in RFC4306. Now we are writing standard track document when
> revising RFC4306 and in that case we can even change things specified
> in RFC4306, if needed. In this case I do not think we need to change
> things from RFC4306, but I think the text in RFC4718 is not correct as
> it does not consider the case completely.

I'm not sure this makes RFC4718 incorrect.  It just makes it incomplete.

> This solution might cause peers to stay in live lock state, causing
> the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and
> host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to
> host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host
> B's Create Child SA request. Both ends process replies, and notices
> they failed, thus both start again, causing both ends to be trying
> these operations as fast as they can. This situation will stay as it
> is unless something kicks hosts out of sync.
>
> Or returning NO_ADDITIONAL_SAS might cause other end to delete the
> whole IKE SA and start from scratch.

I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that
a rekey is being rejected because there are outstanding requests.  To me
a new notify would have made sense.  Given that RFC 4718 did use
NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying
the IKE_SA it should assume the peer is busy when it receives
NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey
the IKE SA again.

I do not agree that when Host B receives NO_ADDITIONAL_SAS that it
should retry the operation using the same IKE SA.  As such I do not think
there is a live lock state.  What should be done is up to the
implementation.  An implementation could assume the other end is in the
process of rekeying or deleting the IKE SA and delay taking any action
or it could take immendiate action.  If it takes immediate action it
would need to do so on a new IKE SA.

> This is not in RFC4306, this is just one proposal given in RFC4718
> which might be used, but as I noted above, it can cause live lock
> loop, thus it is not really acceptable.

I think it is appropriate to add this to the new draft.  If you are
concerned about the lock state then a warning should be added stating
that when you receive NO_ADDITIONAL_SAS that you should not attempt to
retry that operation on the same IKE SA, although that seems
self-evident.

> The proposed solution in RFC4718 does not really work, so I do not
> think we should include that to RFC4306 (yes, I know I should have
> noticed this when RFC4718 was being processed not now, but better now
> than never).

I'm not convinced it is broken, I'm just convinced that if you
attempt to retry an operation on the same IKE SA that you received
NO_ADDITIONAL_SAS on that you can get into a lock state.  To reduce that
concern we can come up with a new REKEYING_IKE_SA notification, but that's
likely to cause problems with old implementations, so better to stick with
what RFC 4718 proposed.

> The text above implies that regardless what you do you should be able
> to allow other end to start exchanges and process them. I.e. IKEv2
> protocol tries to be specified in such way that both ends can start
> exchanges at any times and expect them to either fail or succeed and
> get reply back, but not stay in situation where you do not know,
> whether other end processed your request or not.
>
> If you delete the IKE SA immediately that will happen.

You can never guarantee you are going to get a response back to a
request.  I do not see what makes this situation any different.

> As the RFC4718 text can make situatuation much worse by causing live
> lock, I think that solution proposed there isn't usable as is.

I do not agree.

> Informational RFC 4718 proposes much bigger change to the standard
> track RFC 4306 than what I want to do and also the solution has
> problems which needs to fixed first before it can be taken to
> IKEv2bis. I would propose much smaller change to the RFC4306, which
> says that wait a while before deleting the IKE SA after successful
> rekey so that exchanges from other end has time to finish before
> deleting the IKE SA. Those exchanges happening after the IKE SA was
> rekeyed should either be failed or if they are processed, they should
> be processed in such way that they are done on the Child SAs which are
> already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec
> SAs should be failed, and deleting IPsec SAs should be processed, so
> that IPsec SAs is deleted from the IKE SA where it was moved to).

Everything in RFC 4718 is allowable in 4306.  Both proposals may require
an implementation to change their processing.  I do not think these
proposals are incompatible.

> That is not my reading of the text. But I think it is bit pointless to
> argue about this text as I think we can only agree that it is not
> clear.

Agreed

> There i

Re: [IPsec] #22 Simultaneous IKE SA rekey text

[David Wierbowski]

>> I agree with what you stated here, but I feel you are addressing
something
>> that is not limited to a simultaneous rekey of the IKE SA.  It deals with
>> any
>> rekey of an IKE SA.  In my opinion the text is misplaced and should be in a
>> section that deals with handling of outstanding exchanges when an IKE SA
>> is rekeyed.
>
>True. This wait is not really because of simultaneous rekey, but rekey
>in general. The reason I brought this up here, is that I think that
>wait is important and the solution for simulatenous rekey should be
>one that works with such wait.
>
>> With that said I'm not sure I agree with how you propose to
>> handle the outstanding exchanges.
>
>I do not think there is any other way than to wait some time to get
>them finished (or at least failed and acked). The other end who
>started those outstanding exchanges MUST know whether they were
>processed or not. If IKE SA is deleted immediately there is no way
>other end can know that as after IKE SA is deleted the other end does
>not send ACKs back.

RFC 4718 states:

   It seems this situation is tricky to handle correctly.  Our proposal
   is as follows: if a host receives a request to rekey the IKE_SA when
   it has CHILD_SAs in "half-open" state (currently being created or
   rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
   receives a request to create or rekey a CHILD_SA after it has started
   rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.

If you have outstanding requests to rekey a CHILD SA when you get
a request to rekey the IKE SA you should respond with
NO_PROPOSAL_CHOSEN.  Given that is seems reasonable that you would not
start the rekey of an IKE SA while you have outstanding requests to rekey
a child SA, but if you did then it would make sense that you'd delay
sending the delete request associated with your own successful rekeying
of the IKE SA until those outstanding requests have been responded to.

If you follow 4718 the only request you can have outstanding when you
send a non-error response to an IKE SA rekey request is your own request
to rekey the IKE SA.

>
>> >   I agree it should mark the SA so that it is no longer used for the new
>> >   SAs initiated from this end, but the other end might have its own
>> >   exchanges ongoing when the rekey started, and waiting those to finish
>> >   makes protocol work better. When both end mark the old SA as being
>> >   "old", meaning no new exchanges are started on it, but old exchanges
>> >   are allowed to finished then when those old exchanges are finished,
>> >   then the old IKE SA should be deleted (and all operations done on the
>> >   old IKE SA should be moved to the winning SA).
>>
>> This sounds like a good idea, but it's not what 4306 required and is a
>> protocol change.
>
>Not really. The RFC4306 do say that you MUST be able to process
>incoming requests while having your own requests out:
>
>2.3.  Window Size for Overlapping Requests
>...
>     An
>   IKE endpoint MUST be prepared to accept and process a request while
>   it has a request outstanding in order to avoid a deadlock in this
>   situation.  An IKE endpoint SHOULD be prepared to accept and process
>   multiple requests while it has a request outstanding.
>
I see nothing in this text that says you must delay deleting the IKE SA
or accept new requests on an IKE SA that you've rekeyed.  That is what
you wish to do and that is a protocol change.

>I.e. when you have REKEY started and even when the rekey itself has
>finished, and delete request sent out (and even replied), you still
>might receive requests from the other end which were started before
>the REKEY was started.

If RFC 4718 is followed the only outstanding create child request that
can be received is a request to rekey the IKE SA.  There is little
value in waiting for this.  When the peer receives the request to
delete that IKE SA it will know one of two things happened.

The first is the simultaneous rekey was not detected by both peers.  The
second is the simultaneous rekey was detected by both peers and the peer
sending the delete did not have the lowest nonce.  These are the only
valid reasons for receiving a delete in this case.

>
>I agree that the behavior how to handle the deleting of IKE SA after
>rekey is not described explicitly in RFC4306, but the generic text
>that you MUST be able toprocess incoming requests while having your
>own requests out is there, and that is regardless what those requests
>are.
>
>
>> Based on 4306 I think when an informational exchange request is received
>> containing the delete of an IKE_SA that the receiver can conclude that most
>> likely any outstanding request will fail once a response to the delete is
>> sent.  The receiver of the delete request has ways to deal with this.
>
>The other end cannot know that, and IKEv2 is deterministic protocol,
>thus such "most likely" is not enough for it. Here is example to show
>the situ

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED notify text

[David Wierbowski]

I posted this a last week and have not seen any comments:

Section 3.6 of ikev2bis-04 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."

Section 3.7 of  ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED
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)."

Section 3.10.1 of  ikev2bis-04 indicates that section 3.6 should be
consulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED
notification.

I think section 3.10.1 should say "see section 3.7" as the text that was
associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RFC 4306 is now in
Section 3.7.

I also question the accuracy of the statement in Section 3.6.  Section 3.7
implies that certificate payloads should still be sent when an
HTTP_CERT_LOOKUP_SUPPORTED notify is received; however, an encoding type of
12 or 13 should be used if possible as the peer has indicated a preference
to receive certificate specifications in that format.


Dave Wierbowski___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #22 Simultaneous IKE SA rekey text

[David Wierbowski]

>Tero Stated:
>
>   Deleting the IKE SA immediately makes it impossible to know what
>   happened to other exchanges going on the same IKE SA. Waiting for 30
>   seconds or so after rekey would allow those other exchanges to finish
>   before the old IKE SA is deleted.
>
>   The current IKEv2 document does not specify what happens to the
>   ongoing exchanges when IKE SA is deleted. In normal case that does not
>   matter, as all the IKE SA state goes away when SA is deleted, thus it
>  is simply the case that all exchanges are immediately discarded and
>   all CHILD_SAs on the IKE SA are deleted.
>
>This is not the case on the rekey case, as here there might be
>   CREATE_CHILD_SAs and other exchanges ongoing on the IKE SA when it is
>   rekeyed. Now if the IKE SA is deleted immediately without waiting
>   those to finish when rekey finishes the other end does not know what
>   the node deleting the IKE SA did for those exchanges. It might have
>   silently discarded them, or it might have already processed them but
>   their responses were lost because of network error etc.

I agree with what you stated here, but I feel you are addressing something
that is not limited to a simultaneous rekey of the IKE SA.  It deals with
any
rekey of an IKE SA.  In my opinion the text is misplaced and should be in a
section that deals with handling of outstanding exchanges when an IKE SA
is rekeyed.  With that said I'm not sure I agree with how you propose to
handle the outstanding exchanges.

>   I agree it should mark the SA so that it is no longer used for the new
>   SAs initiated from this end, but the other end might have its own
>   exchanges ongoing when the rekey started, and waiting those to finish
>   makes protocol work better. When both end mark the old SA as being
>   "old", meaning no new exchanges are started on it, but old exchanges
>   are allowed to finished then when those old exchanges are finished,
>   then the old IKE SA should be deleted (and all operations done on the
>   old IKE SA should be moved to the winning SA).

This sounds like a good idea, but it's not what 4306 required and is a
protocol change.

Based on 4306 I think when an informational exchange request is received
containing the delete of an IKE_SA that the receiver can conclude that most
likely any outstanding request will fail once a response to the delete is
sent.  The receiver of the delete request has ways to deal with this.

It can delay sending a response until it receives responses to all
outstanding requests.  It can send a response immediately and conclude
that all outstanding requests will fail.  In that case it can restart the
outstanding request on a newer IKE_SA or wait for traffic to require the
creation of a new SA.

If one of the outstanding requests is for a perceived simultaneous rekey
it now knows it was not perceived that way by the peer.  In this case
it should move the child SAs to the newer IKE SA.  Even with your solution
an
implementation has to be able to handle the case where a perceived
simultaneous rekey of the IKE SA fails.

>
>   NO_ADDITIONAL_SAS is not correct error for this case, as we are
>   talking about IKE SAs not about CHILD_SAs. The NO_ADDITIONAL_SAS
>   description clearly says it is used when no more CHILD_SAs are to be
>   used.

Correct, sorry I misspoke.  We actually send NO_PROPOSAL_CHOSEN, but the
same
logic still applies.  I believe we used to send NO_ADDITIONAL_SAS, but
due to previous discussion on the mailing list we switched to
NO_PROPOSAL_CHOSEN.

>   Sending some more suitable error could most likely also work, but
>   still the IKE SA cannot be deleted immediately. It can only be deleted
>   when ongoing exchanges have been finished.
>
>   I have not checked out if your suggested version works with all
>   possible combinations of simulatenous rekeys, but from the first look
>   it seems it might also work.
>
>   On the other hand there is no text indicating such behavior in the
>   IKEv2 document, so it is protocol change compared to the old text
>   which said that simulatenous rekey is processed by checking out the
>   nonces. The rekeys in this case are simulatenous even when Host A
>   didn't initially detect that.
>

Agreed, so we have two possible protocol changes if we need to mandate one
or we could allow implementations solve the problem as they see fit. I
think
my solution is consistent with what is stated in Section 5.11.4 of RFC
4718.
You are introducing the need to detect a simultaneous rekey after the fact.

>   We do delay the delete, as we do want to wait for the ongoing
>   exchanges to finish. On the other hand we are almost only one of the
>   implementations who also implement the window size > 1, which means we
>   have cases where might have several CREATE_CHILD_SA exchanges
>   initiated by the host B ongoing when host A decides to do rekey on the
>   IKE SA.

We have tested our code using a window size greater than 1.

>
>   That delay does not hav

Re: [IPsec] #22 Simultaneous IKE SA rekey text

[David Wierbowski]

>Tero states:

>  The basic case is where both ends notice this is simultaneous
>  rekey, and can delay moving of the CHILD_SAs until they know which
>  one wins. The more complex case happens where there is dropped
>  packets and one end does not detect simultaneous rekey until it has
>  already finished its rekey and moved CHILD_SAs. As the basic case
>  can be processed in similar way as the more complex case, this
>  example here only covers the more complex case.
>
>  In this case host A and B has IKE SA up and running and both ends
>  decide to rekey it:
>
>  Host AHost B
>---  ---
>send req1: ... Ni1  ... -->
> <-- send req2: ... Ni2 ...
>  --> recv req1
>
>  Now if the req2 is dropped for some reason, the Host A does not
>  know there is simultaneous rekey, but host B will know it when it
>  receives the req1. It will process the req1, but it cannot yet move
>  the CHILD_SAs as it does not know the Nr2. It postpones the
>  CHILD_SA moving until the req2/resp2 rekey finishes. It sends resp1
>  back to the Host A to answer req1 IKE SA rekey:
>
> <-- send resp1: ... Nr1 ...
>recv resp1 <--
>
>  Now the Host A has finished the IKE SA rekey without knowing it was
>  simultaneous rekey. It will move the CHILD_SAs from the old IKE SA
>  to new rekeyed IKE SA A. It MUST NOT immediately delete the old IKE
>  SA, but instead wait for some time to see in case there was
>  simultaneous rekey ongoing or not. When Host B retransmits its req2
>  the Host A will notice that there was simultaneous rekey going on,
>  and it will send normal reply to that:
>
I see no reason why Host A MUST NOT immediately delete the old IKE SA.
In fact I think is SHOULD immediately delete the old IKE SA.  By this
I mean it should mark the SA as being deleted, it should send a delete
payload, and it should refuse to create any additional SAs.
>recv req1 <--
>send resp2: ... Nr2 ... -->
Host A should respond with NO_ADDITIONAL SAS in this case because
Host A did not detect a simultaneous rekey and should have immediately
deleted the original IKE_SA.
>  --> recv resp2
Host B should receive the NO_ADDITIONAL_SAS notification and it should
realize that Host A did not detect the simultaneous rekey.  Host B
should now move the child SAs from the original IKE SA to the one
initiated by Host A.  In reality, it's more likely that Host B has
already received Host A's delete notification and will ignore the
response.
>
>  After sending that reply that also creates the second IKE SA B in
>  Host A and then Host A can check all the four nonces and see which
>  of them is lowest, and it will then move all the CHILD_SAs to that
>  new IKE SA having lowest nonce unless they were already there (i.e.
>  if the IKE SA A had lowest nonce, Host A has already moved the
>  CHILD_SAs there, if IKE SA B had lowest nonce, host A needs to move
>  CHILD_SAs from the IKE SA A to this IKE SA B, and start timer to
>  delete IKE SA A).
Why do you want to mandate all this complication for a case that will
occur infrequently?  You are impacting every IKE_SA rekey, not just
the simultaneous case.  I doubt that anybody delays the delete of an
IKE_SA on a rekey based on RFC 4306.  At the very least I'm sure there
are implementations that do not delay the delete.  Requiring this
delay is a protocol change and one that I do not see the need for.

If Host A deletes the IKE_SA immediately then either Host B will see
the delete and be able to infer that there is no simultaneous rekey or
Host B may also get a NO_ADDITIONAL SAS notification and be able to
infer that there is no simultaneous rekey.
>
>  When Host B receives the resp2 it knows that simultaneous rekey is
>  finished, and it can check the nonces and move CHILD_SAs from the
>  original IKE SA to either IKE SA A or B depending which had lowest
>  nonce. If it was IKE SA A, the host B needs to start timer to
>  delete IKE SA B.
>
>  Depending who created the winning rekeyed IKE SA decides who is
>  going to delete the old IKE SA, i.e. the one who created the
>  winning IKE SA also cleans up the old IKE SA.
>
>  Note, that Host B processing is identical to the basic case where
>  host notices during processing that there is simultaneous rekey
>  ongoing.
>
>  In case the Host A didn't wait for long enough before start
>  deleting old IKE SA there can be case where host B is still trying
>  to retransmit its req2 in the old IKE SA when it receives the
>  delete to the old IKE SA. In that case it knows that Host A has NOT
>  received any of its requests, thus is unaware that there is
>  simultaneous rekey ongoing, thus it can safely stop retrasnmitting
>  req2, and allow old IKE SA to be deleted, and move all CHILD_SAs to
>  the IKE SA A created by Host A.
And i

Re: [IPsec] Populating ID_DER_ASN1_DN

[David Wierbowski]

Yoav (and also Raj),

Thanks for the clarification.  The text in 4301 makes sense.  What I do not
agree with is the text in 4945 that requires implementations MUST be able
to perform matching based on a bitwise comparison of the entire DN in ID to
its entry in the SPD.  I can agree with saying that implementations MUST be
able to perform matching of the entire DN in ID to its entry in the SPD.
It's the "based on a bitwise comparison" that I do not agree with.  It
should be up to the implementation to decide if it wants to do a bitwise
match or use normal x.500 DN matching rules.

It's certainly not an interoperability issue if I decide to use  x.500 DN
matching rules to do the lookup.  Anything that's a binary match will be a
match using x.500 DN matching rules.  There's no security issue using x500
matching rules.

Since we aren't doing a revision of RFC 4945 it's a moot point.  If we ever
do re-spin 4945 then it's a requirement that I think could be relaxed.

Dave Wierbowski


z/OS Comm Server Developer

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





   
  From:   Yoav Nir
       
  To: David Wierbowski/Endicott/i...@ibmus  
   
  Cc: "ipsec@ietf.org" 
   
  Date:   09/17/2009 02:50 AM  
   
  Subject:Re: [IPsec] Populating ID_DER_ASN1_DN
   
  Sent by:ipsec-boun...@ietf.org   
       





On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:

> Section 3.1.5 of RFC 4945 states that when generating an ID type of
> ID_DER_ASN1_DN that "implementations MUST populate the contents of
> ID with the Subject field from the end-entity certificate, and MUST
> do so such that a binary comparison of the two will succeed."
> Section 3.1.5 is specific to IKEv1. There is no such requirement
> listed in Section 4 which is applicable to IKEv2.
>
> What is the purpose of this requirement and why is it only
> applicable to IKEv1?
>
> I believe in the past it has been said that the requirement exists
> because smaller devices may not be capable of performing DN
> matching. If that's the case it seems the issue would be applicable
> to IKEv2 as well.
>
> Section Section 3.1.5 also states, "Regarding SPD matching,
> implementations MUST be able to perform matching based on a bitwise
> comparison of the entire DN in ID to its entry in the SPD. However,
> operational experience has shown that using the entire DN in local
> configuration is difficult, especially in large-scale deployments.
> Therefore, implementations also MUST be able to perform SPD matches
> of any combination of one or more of the C, CN, O, OU attributes
> within Subject DN in the ID to the same in the SPD."
>
> What is the purpose of requiring the ability to match on a bitwise
> comparison of the entire DN if it is also acceptable to match any
> combination of one or more of the C, CN, O, OU attributes? It seems
> that only implementing the second MUST would be sufficient. If the
> ID matches a bitwise comparison of the entire DN it will also match
> a combination of one or more of the C, CN, O, OU attributes.
>
>
> Dave Wierbowski
>
>
Hi Dave.

The difference here is not between IKEv1 and IKEv2, but with the
difference between the two versions of IPsec, as in RFC 2401 vs 4301.

RFC 4301 did a far better job of specifying the relationship between
PAD entries and the IKE IDs, so it was not necessary for RFC 4945 to
specify this.

Section 4.4.3 discusses this thoroughly, especially this paragraph
from 4.4.3.2:

This document does not require that the IKE ID asserted by a peer be
syntactically related to a specific field in an end entity
certificate that is employed to authenticate the identity of that
peer.  However, it often will be appropriate to impose such a
requirement, e.g., when a single entry represents a set of peers
each
of whom may have a distinct SPD entry.  Thus, implementations MUST
provide a means for an administrator to require a match between an
asserted IKE ID and the subject name or subject alt name in a
certificate.  The former is applicable to IKE IDs expressed as
distinguished names; the latter is appropriate for DNS names, RFC
822
e-

[IPsec] Populating ID_DER_ASN1_DN

[David Wierbowski]

Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
the Subject field from the end-entity certificate, and MUST do so such that
a binary comparison of the two will succeed."  Section 3.1.5 is specific to
IKEv1.  There is no such requirement listed in Section 4 which is
applicable to IKEv2.

What is the purpose of this requirement and why is it only applicable to
IKEv1?

I believe in the past it has been said that the requirement exists because
smaller devices may not be capable of performing DN matching.  If that's
the case it seems the issue would be applicable to IKEv2 as well.

Section Section 3.1.5 also states, "Regarding SPD matching, implementations
MUST be able to perform  matching based on a bitwise comparison of the
entire DN in ID to its entry in the SPD.  However, operational experience
has shown that using the entire DN in local configuration is difficult,
especially in large-scale deployments.  Therefore, implementations also
MUST be able to perform SPD matches of any combination of one or more of
the C, CN, O, OU attributes within Subject DN in the ID to the same in the
SPD."

What is the purpose of requiring the ability to match on a  bitwise
comparison of the entire DN if it is also acceptable to match any
combination of one or more of the C, CN, O, OU attributes?  It seems that
only implementing the second MUST would be sufficient.  If the ID matches a
bitwise comparison of the entire DN it will also match a combination of one
or more of the C, CN, O, OU attributes.


Dave Wierbowski



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] HTTP_CERT_LOOKUP_SUPPORTED notify text

[David Wierbowski]

Section 3.6 of ikev2bis-04 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."

Section 3.7 of  ikev2bis-04, says "The HTTP_CERT_LOOKUP_SUPPORTED
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)."

Section 3.10.1 of  ikev2bis-04 indicates that section 3.6 should be
consulted for an explanation of the HTTP_CERT_LOOKUP_SUPPORTED
notification.

I think section 3.10.1 should say "see section 3.7" as the text that was
associated with the HTTP_CERT_LOOKUP_SUPPORTED notify in RFC 4306 is now in
Section 3.7.

I also question the accuracy of the statement in Section 3.6.  Section 3.7
implies that certificate payloads should still be sent when an
HTTP_CERT_LOOKUP_SUPPORTED notify is received; however, an encoding type of
12 or 13 should be used if possible as the peer has indicated a preference
to receive certificate specifications in that format.

Dave Wierbowski___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #26: Missing treatment of error cases

[David Wierbowski]

Yoav,

You are sending an informational notification, so how could you say the SA
does not exist and no delete should be sent?

If  an authentication error is discovered when processing the IKE_AUTH
response then responder thinks an IKE SA exists and the initiator intends
to delete that SA.  In this case it seems clean for the initiator to send
an INFORMATIONAL exchange containing AUTHENTICATION_FAILED and treating the
SA as being deleted.  I do not see the harm in including a DELETE in this
case and it seems to be a more appropriate action than sending the
AUTHENTICATION_FAILED.

I'm fine with not requiring the DELETE, but I don't think including the
DELETE is bad and should be discouraged.  I think it reinforces the
initiator's intentions and is unambiguous.

Dave Wierbowski



   
  From:   Yoav Nir
   
  To: David Wierbowski/Endicott/i...@ibmus  
   
  Cc: "ipsec@ietf.org" , Keith Welter/Raleigh/i...@ibmus
   
  Date:   09/04/2009 03:25 PM  
   
  Subject:Re: [IPsec] Issue #26: Missing treatment of error cases  
   
  Sent by:ipsec-boun...@ietf.org   
   






On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote:



  >Yes, I will soften the language a bit, but I won't mention a DELETE
  payload. If some implementations do it.
  >others may come to expect it. We don't want to encourage that by
  suggesting that it's a good idea.

  Yoav, Why is it a a bad idea to include a DELETE payload in this
  case?



Because the IKE SA was not really created, so there is no IKE SA to delete.
It's a bad idea because it is superfluous, and we don't want to risk anyone
relying on this.___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

<><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #26: Missing treatment of error cases

[David Wierbowski]

>Yes, I will soften the language a bit, but I won't mention a DELETE
payload. If some implementations do it.
>others may come to expect it. We don't want to encourage that by
suggesting that it's a good idea.

Yoav, Why is it a a bad idea to include a DELETE payload in this case?


Dave Wierbowski___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] CRL checking when selecting a certifcate

[David Wierbowski]

Tero, thanks for the comments and the clarification on how to read a lower
case must.  I do have a few more comments.

>So implementations cannot just search uppercase "MUST/SHOULD/MAY"
>texts and assume it is enough to make sure those are correct. It also
>needs to do what the text says...
>
I think most implementers focus on the MUST and SHOULDs and then apply
common sense to the remaining text.

>> CRL checking is not cheap and
>> performing CRL checking when selecting a certificate seems like an
optional
>> usability feature to me.
>
>The you probably want to make change to the current text which says
>you must do it...
Correct.  I think when selecting a certificate that consulting revocation
information is a lower case should or could at best.  I agree that on the
accepting side a lower case must is appropriate for revocation checking
from an interoperability perspective.  By that I mean the failure to do so
will not hinder interoperability, but from a security perspective it really
should be done.


Dave Wierbowski


z/OS Comm Server Developer

 Phone:
Tie line:   620-4055
External:  607-429-4055
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] CRL checking when selecting a certifcate

[David Wierbowski]

In a recent append Tero said:

>Then the responder is already going against the RFC4306 which says
>"Certificate revocation checking must be considered during the
>chaining process used to select a certificate. " meaning the responder
>cannot send certifiate which itself considers revoced. Only case when
>this can happen is when responder thinks he has valid certificate but
>initiator then checks it against certificate authority's system (for
>example OCSP) and finds out it is not valid anymore. This is not
>common case, thus it can lead to timeouts.

This is a lower case must.  I'm not sure it is safe to assume that
implementations adhere to a lower case must.  CRL checking is not cheap and
performing CRL checking when selecting a certificate seems like an optional
usability feature to me.  From the sender's point of view the worst thing
that is going to happen is the receiver will fail the authentication
because the certificate is revoked.  The only advantage to doing the check
on the sender's side is there is a chance the sender can find a non-revoked
certificate, but I think the decision to perform that optimization is
implementation specific.


Dave Wierbowski
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #107: Sending certificate chains in IKEv2

[David Wierbowski]

>David Wierbowski writes:
>> I agree with Tero that Yoav's proposed text adds clarity and effectively
it
>> does not add a new MUST; however, to address Paul's concern can we just
>> change the words "MUST be" to the word "are" or lower case "should be?"
>> For example:
>>
>>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 are used, only the
>>   first of which holds the public key used to validate the sender's
>>   AUTH payload.
>
>This text looks good for me. And I think it is important to add this
>to X.509 Certificate - Signature (4) case, even when we have some
>generic text elsewhere saying same thing, as this is the most common
>case people are using now.
>
>> As Tero points out, this is the only way to send a chain this using
X.509
>> Certificate - Signature.encoding.  MUST terminology really is not needed
in
>> my opinion.
>
>Agreed.
>
>I think in addition to that text we might want to add some generic
>text to the final paragraph saying:
>
>   Some of the certificate formats can only contain one certificate
>   (for example formats 4, 7, 11 and 12), and some can contain
>   multiple certificates (for example 1, 13). In case those formats
>   which contain one certificate are used and multiple certificates
>   are to be sent then each certificate are sent as separate
>   Certificate Payload.
>

I agree that text like this should be added.  I suggest some minor
editorial changes (change "In case those formats" to "When" and
"are" to "is":

Some of the certificate formats can only contain one certificate
(for example formats 4, 7, 11 and 12), and some can contain
multiple certificates (for example 1, 13). When formats
which contain one certificate are used and multiple certificates
are to be sent then each certificate is sent as separate
Certificate Payload.

In that past I've asked if the first certificate payload is encoded
using type 13 does the first certificate in the bundle have to be
the one used to create the signature and you've answered yes.  Perhaps
we should also clarify that here.  I do not think we can make such
a statement when type 1 is used.  I know of at least one vendor that
uses type 1.  The signing cert is not the first certificate in their
PKCS #7 data.

>
>Or add similar text than what is in the 3.7 Certificate Request
>Payload which have following sentence at the end of first paragraph
>"If multiple CAs are trusted and the certificate encoding does not
>allow a list, then multiple Certificate Request payloads would need to
>be transmitted."

I prefer your previous wording.

>
>One more thing, do we want to explictly mention that it is very common
>to mix multiple types of certificate payloads, i.e. send certificate
>multiple payloads some having X.509 Certificate - Signature (4) format
>and some having Certificate Revocation List (7) format.
>

I agree that we should state that mixing multiple types of
certificate payloads is allowed.  The examples are helpful,
but I'm not sure we need to include them in the text.

>Another combination could be Raw RSA Key (11) and X.509 Certificate -
>Signature (4). In that case the Raw RSA Key (11) format is meant for
>minimal implementations who have the raw RSA key of the other end
>statically configured to their policy, and the X.509 Certificate -
>Signature (4) format is meant for full implementations which can
>process and validate certificates.
>
>Note also that not all certificates are there to form a chain, they
>can also provide other things like CRLs or even multiple different
>chains towards the different CAs (in case the private/public key use
>has certificates from multiple CAs, and other end didn't indicate any
>known CA), so the extra certificate payloads (after the first one used
>to sign the AUTH payload) are there just to help validation of the
>first certificate, not necessarely to form a chain.

I agree that we should stste the extra certificate payloads are there to
help validation of the first certificate, not necessarely to form a single
chain.

>--
>kivi...@iki.fi___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #107: Sending certificate chains in IKEv2

[David Wierbowski]

I agree with Tero that Yoav's proposed text adds clarity and effectively it
does not add a new MUST; however, to address Paul's concern can we just
change the words "MUST be" to the word "are" or lower case "should be?"
For example:

   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 are used, only the
  first of which holds the public key used to validate the sender's
  AUTH payload.

As Tero points out, this is the only way to send a chain this using X.509
Certificate - Signature.encoding.  MUST terminology really is not needed in
my opinion.

Dave Wierbowski





   
 Tero Kivinen  
   
 Sent by:   To
 ipsec-boun...@iet Yaron Sheffer   
 f.org  
cc
   "ipsec@ietf.org" 
 08/26/2009 09:42  Subject
 AM[IPsec]  #107: Sending certificate
   chains in IKEv2 
   
   
   
   
   
   




Yaron Sheffer writes:
> What this doesn't say is how we send this chain of certificates.  Is it
> multiple separate CERT payloads (in that case it should say so) or is it
a
> single CERT payload (and then we should also say so)

If you use format that can only store one certificate (for example
X.509 Certificate - Signature (#4), or Hash and URL of X.509
certificate (#12)) then you send multiple Certificate Payloads each
having one certificate in, and the first certificate payload you send
contains the certificate you use to sign the AUTH payload.

If you use format that can store multiple certificates (PKCS #7
wrapped X.509 certificate (#1) or Hash and URL of X.509 bundle (#13))
then the first certificate inside the first Certificate Payload is the
one used to sign the AUTH payload.

This thing is same as it was in IKEv1, i.e. sending multiple
Certificate payloads, each having one certificate using X.509
Certificate - Signature (#4) was the most common configuration
implementations supported.

Note, that it is also valid to send mixed set of certificate payloads,
i.e. send first few Certificate Payloads using X.509 Certificate -
Signature (#4) format and then send couple of Certificate Payloads
using Certificate Revocation List (CRL) (#7) format, to provide the
CRLs for those certificates.

I already had some comments to this at 2008-07-29, where I requested
change to the "X.509 Certificate - Signature" description, so it would
be clear that it can also be used in validation of the chain not only
when validating AUTH payload
http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html,
actually Yoav Nir's version has even better text
http://www.ietf.org/mail-archive/web/ipsec/current/msg04326.html (and
disagree with Paul's comment that this text would add new MUST, as
that requirement has always been there as there is no way to encode
multiple certificates to one X.509 Certificate - Signature (#4)
format, thus if you want to use that format you must have sent
multiple certificates earlier too (note that the MUST was only "with
this encoding")). On the other hand as this thing with multiple CERT
payloads is not only restricted to that format, so some generic text
to section 3.6 is needed anyways.

There is also my previous email about this #107 ticket, which includes
some more comments to the issue:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04327.html.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #107: Sending certificate chains in IKEv2

[David Wierbowski]

We use multiple certificate payloads when using  X.509 Certificate -
Signature (4) encoding.

I do not really see how this could be questioned.  RFC 4306 clearly says
X.509 Certificate - Signature (4) encoding contains a single certificate as
pointed out below.  The logical conclusion is that if you need to send
multiple certificates and choose to use  X.509 Certificate - Signature (4)
encoding then you need multiple payloads.

On the other hand you can send one payload if you use Hash and URL of X.509
bundle encoding.  If you do then the first certificate in the bundle must
contain the public key used to sign the AUTH payload.

I think the existing text is fine.



Dave Wierbowski








   
 Yaron Sheffer 
  To
 Sent by:  "ipsec@ietf.org" 
 ipsec-boun...@iet  cc
 f.org 
   Subject
   [IPsec] #107: Sending certificate
 08/25/2009 05:23  chains in IKEv2 
 PM
   
   
   
   
   




Yoav says:

Section 3.6 ("Certificate Payload") describes sending certificates in the
IKE_AUTH exchange.  The usual format for sending certificates is #4 (X.509
Certificate - Signature). Here's what it says:


{{{
   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 the singular)  The last paragraph says:


{{{
   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication...
   ...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.
}}}

What this doesn't say is how we send this chain of certificates.  Is it
multiple separate CERT payloads (in that case it should say so) or is it a
single CERT payload (and then we should also say so)


Input from actual implementations (and bakeoffs) will be most valuable
here.

Thanks,
Yaron(See attached file: smime.p7s)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>

smime.p7s
Description: Binary data
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2 bis section order

[David Wierbowski]

Yaron,

Your proposed reordering seems fine to me.  I agree with moving section 1.7
to an appendix.  Moving  sections 1.2-1.5 to sections 2-2.4 does not add a
great deal of value, but does make sense. I think either way is fine. I
have no preference realtive to the section 1.2-1.5 move.

Dave Wierbowski


z/OS Comm Server Developer

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





   
 Yaron Sheffer 
  To
 Sent by:  "ipsec@ietf.org" 
 ipsec-boun...@iet  cc
 f.org 
   Subject
   [IPsec] IKEv2 bis section order 
 07/01/2009 12:36  
 PM
   
   
   
   




Hi,

RFC 4306 has an extremely long introductory section, which basically
contains a normative description of the main protocol exchanges. In v2bis,
we tried to stick to the original section order, but I think that making a
change here would make the document much more understandable, especially to
newcomers. I suggest to keep the introduction short, and move the normative
description of the basic protocol exchanges into its own section.

So instead of the current:

   1.  Introduction
 1.1.  Usage Scenarios
   1.1.1.  Security Gateway to Security Gateway Tunnel Mode
   1.1.2.  Endpoint-to-Endpoint Transport Mode
   1.1.3.  Endpoint to Security Gateway Tunnel Mode
   1.1.4.  Other Scenarios
 1.2.  The Initial Exchanges
 1.3.  The CREATE_CHILD_SA Exchange
   1.3.1.  Creating New Child SAs with the CREATE_CHILD_SA
   Exchange
   1.3.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
   1.3.3.  Rekeying Child SAs with the CREATE_CHILD_SA
   Exchange
 1.4.  The INFORMATIONAL Exchange
   1.4.1.  Deleting an SA with INFORMATIONAL Exchanges
 1.5.  Informational Messages outside of an IKE SA
 1.6.  Requirements Terminology
 1.7.  Differences Between RFC 4306 and This Document
   2.  IKE Protocol Details and Variations

I'd like to propose:

   1.  Introduction
 1.1.  Usage Scenarios
   1.1.1.  Security Gateway to Security Gateway Tunnel Mode
   1.1.2.  Endpoint-to-Endpoint Transport Mode
   1.1.3.  Endpoint to Security Gateway Tunnel Mode
   1.1.4.  Other Scenarios
 1.2.  Requirements Terminology

   2.  IKE Protocol Overview (or "Essentials") [today's Sec. 1.2-1.5]
 2.1.  The Initial Exchanges
 2.2.  The CREATE_CHILD_SA Exchange
   2.2.1.  Creating New Child SAs with the CREATE_CHILD_SA
   Exchange
   2.2.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
   2.2.3.  Rekeying Child SAs with the CREATE_CHILD_SA
   Exchange
 2.3.  The INFORMATIONAL Exchange
   2.3.1.  Deleting an SA with INFORMATIONAL Exchanges
 2.4.  Informational Messages outside of an IKE SA

   3.  IKE Protocol Details and Variations [today's Sec. 2]

   Appendix X: Differences Between RFC 4306 and This Document [today's Sec.
1.7]

Do you see value in this, or do you prefer keeping the existing order?

Thanks,
 Yaron
(See attached file: smime.p7s)
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>

smime.p7s
Description: Binary data
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question

[David Wierbowski]

Did I say either of the quotes you sent make it sound like one could not
sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

I said I'm confused by Tero's previous answer which makes it sound as if
such a restriction is implied.

I guess the value in the HTTP_CERT_LOOKUP_SUPPORTED notify is  that you
know when it is safe to use the hash and URL encoding, but it also allows
you to send the hash and URL encoding to a peer that may have disabled that
support via a configuration option.  That doesn't seem like a good design
to me, but it's certainly flexible :>).

Dave Wierbowski







   
 Paul Hoffman  
  To
 Sent by:      David Wierbowski/Endicott/i...@ibmus
 ipsec-boun...@iet  cc
 f.org ipsec@ietf.org, 
   ipsec-boun...@ietf.org  
   Subject
 05/22/2009 02:04  Re: [IPsec] 
 PMHTTP_CERT_LOOKUP_SUPPORTED question
   
   
   
   
   
   




At 12:08 PM -0400 5/22/09, David Wierbowski wrote:
>Paul,
>
>Thanks, but now I'm confused by an answer Tero provided to a slightly
different question back in July of 2007 (subject [Ipsec] Comments on
draft-hoffman-ikev2bis-01.txt). From Tero's answer I had expected to see
something that would disallow using those encoding types if you did not
receive the HTTP_CERT_LOOKUP_SUPPORTED. See below.

I cannot speak for Tero. I can only say what is in the RFC and the current
draft. Did either of the quotes I sent make it sound like one could not
sent hash-and-URL if HTTP_CERT_LOOKUP_SUPPORTED was not received?

At 5:05 PM +0300 7/19/07, Tero Kivinen wrote:
>HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the
>other end is CONFIGURED to allow HTTP lookups for the certificates.

While that is true, a peer is not required to send it if that peer is
configured to allow HTTP lookups.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question

[David Wierbowski]

Paul,

Thanks, but now I'm confused by an answer Tero provided to a slightly
different question back in July of 2007 (subject [Ipsec] Comments on
draft-hoffman-ikev2bis-01.txt).  From Tero's answer I had expected to see
something that would disallow using those encoding types if you did not
receive the HTTP_CERT_LOOKUP_SUPPORTED.  See below.

> Since an implementation MUST be capable of being configured to send and
> accept the first two Hash and URL formats it's seems to follow that an
> implementation also MUST support HTTP certificate lookup (making the
> HTTP_CERT_LOOKUP_SUPPORTED notification extraneous).  I believe the
intent
> is for HTTP certificate lookup support to be optional but a clarification
> to that effect would be helpful.

HTTP_CERT_LOOKUP_SUPPORTED is not extraneous, as it tells whether the
other end is CONFIGURED to allow HTTP lookups for the certificates.

> Assuming HTTP certificate lookup support is optional, how should an
> implementation handle receipt of a CERT payload containing either of the
> Hash and URL formats (or any other unsupported encoding)?  Presumably the
> implementation should ignore the certificate payload in this case.  Is
> that correct?

If you receive certificate payload you cannot process you can ignore
it and try to see if you can still authenticate the other end. If you
happen to have the certificate for the other end for some other reason
(preconfiguration, cached by previous session etc) then you can
authenticate the other end, if you do not have the certificate you
will fail the authentication.

Dave Wierbowski


z/OS Comm Server Developer

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





   
 Paul Hoffman  
  To
     Sent by:  David Wierbowski/Endicott/i...@ibmus
 ipsec-boun...@iet  cc
 f.org ipsec@ietf.org, 
   ipsec-boun...@ietf.org  
   Subject
 05/22/2009 11:57  Re: [IPsec] 
 AMHTTP_CERT_LOOKUP_SUPPORTED question
   
   
   
   
   
       




At 11:52 AM -0400 5/22/09, David Wierbowski wrote:
>Why?

Because there is nothing in the document to indicate that it is invalid.
HTTP_CERT_LOOKUP_SUPPORTED is only mentioned twice in RFC 4306:

   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.

. . .

HTTP_CERT_LOOKUP_SUPPORTED   16392

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).

Neither of those make it sound like it is required before sending type 12
or 13 certificates.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] HTTP_CERT_LOOKUP_SUPPORTED question

[David Wierbowski]

Why?



Dave Wierbowski


z/OS Comm Server Developer

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





   
 Paul Hoffman  
  To
 Sent by:  David   
 ipsec-boun...@iet Wierbowski/Endicott/i...@ibmus,  
 f.org ipsec@ietf.org  
cc
   
 05/22/2009 11:25  Subject
 AMRe: [IPsec] 
   HTTP_CERT_LOOKUP_SUPPORTED question
   
   
   
   
   
   




At 9:30 AM -0400 5/22/09, David Wierbowski wrote:
>If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my
peer to send me a certificate payload with a hash and URL encoding (i.e. 12
or 13)? I do not see any language in RFC 4306 or 4945 that states the peer
MUST NOT send a certificate payload with a hash and URL encoding in this
case.

It is definitely valid to send those payloads regardless of the notify.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<><><>___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] HTTP_CERT_LOOKUP_SUPPORTED question

[David Wierbowski]

If I do not send an HTTP_CERT_LOOKUP_SUPPORTED notify is it valid for my
peer to send me a certificate payload with a hash and URL encoding (i.e. 12
or 13)?  I do not see any language in RFC 4306 or 4945 that states the peer
MUST NOT send a certificate payload with a hash and URL encoding in this
case.

Dave Wierbowski

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #107

[David Wierbowski]

> Tero said:
>
> 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).

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David Wierbowski]

Tero Kivinen writes:
> Michael Richardson writes:
> > 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?
>
> 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.

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


Dave Wierbowski




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Ticket #9

[David Wierbowski]

Ticket #9 says"If the authentication fails in such ways that the entries
cannot create IKE SA (authentication failure or similar), then the response
will be unencrypted, unauthenticated notify."  Back in January there was
additional discussion about this issue.  Several people supported sending
the response as an encrypted, authenticated notify.  The reason being that
the only entity who can send an encrypted, authenticated notify is the
person with knowledge of  SK_e* and SK_a*.

Have we reach a decision yet?  I thought we decided it was ok to send an
encrypted, authenticated notify in this case and the initiator could take
action on it because he knows it came from the person that he performed the
DH exchange with, but the ticket does not reflect that.

Dave Wierbowski
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #22: simultaneous IKE SA rekeys

[David Wierbowski]

I do not believe the algorithm below is consistent with what was said in
section 5.11.4 of RFC 4718.  Section 5.11.4 of RFC 4718 said:

5.11.4.  Simultaneous IKE_SA Rekeying

   Probably the most complex case occurs when both peers try to rekey
   the IKE_SA at the same time.  Basically, the text in Section 2.8
   applies to this case as well; however, it is important to ensure that
   the CHILD_SAs are inherited by the right IKE_SA.

   The case where both endpoints notice the simultaneous rekeying works
   the same way as with CHILD_SAs.  After the CREATE_CHILD_SA exchanges,
   three IKE_SAs exist between A and B; the one containing the lowest
   nonce inherits the CHILD_SAs.


"After the CREATE_CHILD_SA exchanges" implies the exchanges are expected to
complete before the simultaneous rekey is resolved.  The algorithm below
resolves the simultaneous rekey during the CREATE_CHILD_SA exchange and
only allows one rekey to complete.  My concern is that the algorithm below
will be incompatible with anybody that implemented to RFC 4718.

A slight  tangent to this is that the possibility of a simultaneous
reauthentication exists, however, RFC 4306, RFC 4718, and the current bis
draft does not address that scenario.  Given that the a reauthentication is
done by creating a new IKE_SA from scratch I'm not even sure if it is
possible to detect a simultaneous reauthentication of an IKE_SA, but it
would be nice if we could.




   
 Yoav Nir  
To
 Sent by:  "ipsec@ietf.org" 
 ipsec-boun...@iet  cc
 f.org 
   Subject
   [IPsec] Issue #22: simultaneous IKE
 02/17/2009 05:03  SA rekeys   
 AM
   
   
   
   
   





Hi all.

Section 2.8.1 of the draft discusses what to do when Child SAs are rekeyed
simultaneously by both peers. Issue #22 asks to clarify the same thing for
simultaneous rekeying of IKE SAs.

We've written a proposed additional section, that should be labeled 2.8.2.
Since this specifies new behavior that was not specified before, we want
your comments before putting this into the draft.

Thanks

Yoav


2.8.2.  Simultaneous IKE SA rekeying

   If the two ends have the same key lifetime policies for IKE SAs, it
   is possible that both will initiate a rekeying at the same time.
   This is unacceptable for IKE SAs, because the IKE SAs own the child
   SAs, and deleting the IKE SA leeds to deletion of all child SAs.  To
   reduce the probability of this happening, the timing of rekeying
   requests SHOULD be jittered (delayed by a random amount of time after
   the need for rekeying is noticed).

   To avoid the case of two IKE SAs created by simultaneous
   CREATE_CHILD_SA exchanges, the IKE SA with the lowest of the
   initiator nonces is silently discarded, and the dependent child SAs
   are transferred only to the IKE SA with the higher of the two
   initiator nonces.  Here "higher" and "lower" refer to octet-by-octet,
   lexicographical comparison of the nonces as large integers.

   The rules are as follows:
   1.  If a rekey request is received before this host has sent a rekey
   request of its own, this host MUST NOT send a rekey request.
   Instead, it MUST reply to the rekey request it has received.
   2.  If a rekey request is received after this host has sent a rekey
   request, then this host MUST compare the two initiator nonce
   values.  If the received nonce is higher than its own, it MUST
   reply to the received request, and SHOULD stop retransmissions of
   its own request.  If the received nonce is lower, it MUST ignore
   the received request.
   3.  If a rekey request is received after this host has sent a rekey
   request, and the peer has already replied, the new received
   request MUST be ignored.

   Following these rules should prevent any case of multiple successful
   rekeys of an IKE SA.  The only case where the 2nd rule would be
   needed is if both requests were sent before either of them was
   processed.  The implementation whose rekey request was answered
   SHOULD delete the old IKE SA soon after.  The other implementation
   SHOULD wait at least one minute before

[IPsec] Is an empty CertRequest payload valid in IKEv2?

[David Wierbowski]

In IKEv1 sending empty certificate request was agreed to mean "give me your
cert, any cert".  Does this same concept apply to IKEv2?  RFC 4306 does not
mention the notion of an empty cert request payload.  Section 3.6 of RFC
4306 implies that one may not need to send a certificate request in order
to receive a certificate payload by saying:

   The Certificate Payload, denoted CERT in this memo, provides a means
   to transport certificates or other authentication-related information
   via IKE.  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.

Likewise, RFC 4945 only mentions the notion of an empty certificate request
in Section 3 (Use of Certificates in RFC 2401 and IKEv1/ISAKMP) and
appendix B which is only referenced by Section 3.

If there is no concept of an empty certificate request in IKEv2 why is the
text in section 3.6 a SHOULD and not a MUST?  It seems to me that in order
to ensure interoperability the text in Section 3.6 should read,
"Certificate payloads MUST be included in an exchange if certificates are
available to the sender.  An encoding type of Hash and URL of X.509
certificate or Hash and URL of X.509 bundle MAY be used if the peer has
indicated an ability to retrieve this information using an
HTTP_CERT_LOOKUP_SUPPORTED Notify payload."

Dave Wierbowski


z/OS Comm Server Developer

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec