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

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Sep 2009 17:07:45 +0300

Yoav Nir writes:
> Following is our suggested new text. Please let us know what you  
> think. Also, please take a look at the description of  
> "AUTHENTICATION_FAILED" in section 3.10.1. "response to an IKE_AUTH  
> message" means either an IKE_AUTH response to an IKE_AUTH request, or  
> an INFORMATIONAL request that describes an error in the IKE_AUTH  
> response. Do you think this phrasing is clear enough?

Yes, altought I think most of the implementations do not bother
sending INFORMATIONAL requests when IKE_AUTH response has errors. I
think most implementations will then simply remove the IKE SA as
failed without any further communications to the other end (I do not
know any implementation sending that kind of INFORMATIONAL requests,
but I expect that almost all implementations will act correctly if
someone happen to send them (i.e. they will delete the IKE SA as
failed and send empty reply back)). 

>     All errors that occur in an IKE_AUTH exchange, causing the
>     authentication to fail for whatever reason (invalid shared secret,
>     unrecognized ID, untrusted certificate issuer, revoked or expired
>     certificate, etc.)  MUST result in an AUTHENTICATION_FAILED
>     notification.

This MUST there is too strong, especially for the "unrecognized ID"
part. For example our implementation send AUTHENTICATION_FAILED return
only if processing of AUTH Payload faiiled (i.e. signature check
failed (for RSA/DSA), mac failed for shared keys authentication, or no
valid public key / shared key found for the ID).

In cases where the other end is unknown (i.e. ID is not configured to
the policy) it will return NO_PROPOSAL_CHOSEN as it does not find
valid policy to accept the other ends proposal when looking it based
on the ID.

So at least remove the "unrecognized ID" from the list, as it does not
belong there, and change the "MUST" to "SHOULD" as specifying exactly
one error code in such situations will make lots of implementations
non-conforming. I know that people writing conformance tests are going
to test this kind of things, and I have already several times
explained them that the exact error codes returned by different
implementations can differ depending what checks they do and in which
order. 

> If the error occurred on the responder, the
>     notification MUST be returned in the protected response, and MUST be
>     the only payload in that response.

Again the two MUSTs there will make some implementations
non-conforming. We had discussion about this earlier, and in general
it is good idea to send them encrypted and MACed, but as that was not
required before this is real protocol change. For such I think it
requires more explantion. Also I want to have warning here saying that
even if it is encrypted and MACed, that does not mean it is authentic
from the real recipient. It is coming from the recipient you talked
to, but if there is man-in-the-middle he can also generate such
messages, meaning the initiator should still continue trying with this
peer (he can immediately delete the current IKE SA exchange, as it
cannot succeed after this, but next try might get to the real end node
instead of man-in-the-middle and succeed). 

> If the error occurs on the
>     initiator, the notification MUST be returned in a separate
>     INFORMATIONAL exchange, with no other payloads.

This MUST there is way too strong, as there is no implementations I
know that implements that. For example our implementation simply
consides the IKE SA failed in such case and removes the IKE SA, and
then when next triggering packet comes it will try again.

I would say "MAY" would be correct in this case.

> Note, however, that
>     messages that contain an unsupported critical payload, or that are
>     otherwise malformed, MUST be rejected in their entirety, and only
>     lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX
>     Notification.  The receiver MUST NOT verify the payloads related to
>     authentication in this case.

This "MUST NOT" is again too strong, as in some implementations they
might process payloads in order and depending how deep in which place,
they might for example process AUTH payload before noticing that the
SA payload of the IPsec SA is malformed in its transform substructure.

This "MOST NOT" would make such implementations non-conforming,
meaning every single implementation must do full parsing of the
payloads first and only after that do second phase when it processes
the payloads. 

>     If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
>     is established, provided that there are no unsupported critical
>     payloads.

The "provide that there are no unsupported critical payloads" is
not really needed, as the first part asked to check those first, thus
authentication cannot succeed (it is not even tried) if there is
unsupported critical payload. Even if we allow parsing AUTH payloads
before checking all critical bits, then I do not think that text is
needed, it just confuses people.

This next text should be in its own paragraph as it is not related to
the authentication failures:

> Establishing the child SA, or requesting configuration
>     information may still fail, but they do not automatically cause the
>     IKE SA to be deleted.  Specifically, a responder may include all the
>     payloads associated with authentication (IDr, Cert and AUTH) while
>     sending error notifications for the piggybacked exchanges
>     (FAILED_CP_REQUIRED, INVALID_SELECTORS, NO_PROPOSAL_CHOSEN, etc.),
>     and the initiator MUST NOT fail the authentication because of this.
>     The initiator MAY, of course, for reasons of policy later delete  
> such
>     an IKE SA.
> 
>     Only authentication failures and malformed packets lead to a  
> deletion
>     of the IKE SA without requiring an explicit DELETE payload.  Other
>     error conditions require such a payload.

It would be better to talk about "INFORMATIONAL exchange having DELETE
payload for IKE SA" instead of "DELETE payload", as that is the common
way of doing things. Otherwise some implementation might start adding
DELETE payloads to other requests / replies too, and I don't expect
all imlementations to act on them in all cases.

Currently we do not have any limitiations where DELETE payload can be,
but I would expect most implemenations would ignore it if it is sent
inside the response packet of the CREATE_CHILD_SA exchange.

Even if we do not forbid DELETE payloads in other places, we can use
examples and language that indicate the "normal" place for it.

This following covering IKE_SA_INIT should again be in separate
paragraph: 

> In an IKE_SA_INIT  
> exchange,
>     any error notification causes the exchange to fail.

Not completely true. Even when the exchange fails the creation of the
IKE SA might still continue, for example in cases where
INVALID_MAJOR_VERSION (the initiator can fall back to IKEv1),
INVALID_KE_PAYLOAD (the initiator can change to correct group), or
COOKIE (the initiator tries again with COOKIE payload included (COOKIE
is not really error notification)).

Currently exchange is defined so that this statement is true as in
those cases we start new exchange with same peer. 

> In an IKE_AUTH
>     exchange, or in the subsequent INFORMATIONAL exchnage, only the
>     following notifications cause the IKE SA to be deleted or not
>     created, without a DELETE payload:
>     o  UNSUPPORTED_CRITICAL_PAYLOAD
>     o  INVALID_SYNTAX
>     o  AUTHENTICATION_FAILED
> 
>     Extension documents may define new error notifications with these
>     semantics, but MUST NOT use them unless the peer is known to
>     understand them.

In subsequent INFORMATIONAL exchanges the UNSUPPORTED_CRITICAL_PAYLOAD
should not be fatal. It only means that the responder ignored the
whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That does
not delete IKE SA.

For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
SA as IKE SA is not yet ready.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Sep 2009 17:50:27 +0300

On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote:

> failed without any further communications to the other end

But wouldn't this cause a state de-synchronization?  If the responder  
sends a revoked certificate, the initiator will have no IKE SA, but  
the responder would have an IKE SA, which it thinks is valid. Wouldn't  
this necessarily later lead to requests that time out?

> (I do not

That allows for ID enumeration. It's similar to a password entry form,  
that says "wrong user" or "wrong password".  An attacker would be able  
to verify whether a particular ID (say, user name) exists on a system.

> instead of man-in-the-middle and succeed).

Agree. Will fix tomorrow or Thursday.

> considers the IKE SA failed in such case and removes the IKE SA, and

OK.

> payloads first and only after that do second phase when it processes

How about if we limit this to packets that are malformed in their  
entirety, rather than some particular payload (and packets that have  
unrecognized critical payloads) ?

> needed, it just confuses people.

OK

> examples and language that indicate the "normal" place for it.

OK

> SA as IKE SA is not yet ready.

That's what I meant. I will clarify this.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Sep 2009 15:28:48 +0300

Yoav Nir writes:
> But wouldn't this cause a state de-synchronization?

Yes, but not in normal case.

> If the responder  

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. 

> to verify whether a particular ID (say, user name) exists on a system.

If the other ends source IP-address is not configured to system (and
no wildcard entry found) then it will always return NO_PROPOSAL_CHOSEN
regardless of the ID or AUTH payloads.

Anyways active attacker can always find out the used IDs anyways. Also
from timing it is easy to see whether other end actually did only
database lookup for the ID, or whether he actually verified the RSA
signature.

If you consider ID enumeration a problem that needs to be added to the
Security Considerations section (regardless whether we return
AUTHENTICATION_FAILED or NO_PROPOSAL_CHOSEN in this case). 

> unrecognized critical payloads) ?

If you say MUST in any of these error cases you need to be very
specific which cases are covered, most likely giving similar pseudo
code saying you first check this, and if it fails, return this error
code, then you check this and so on...

Similar than RFC2408 Section 5 did, but even then you most likely get
implementations which do things differently because they just happen
to use some external library or other thing that does parts of the
checks in different order than what is listed in the RFC.

I have been explaining this to several customers when they have run
some external tester which required specific error code to be reported
in specific case, and we returned some other error code because we
checked things in different order.

Thats why it is bad idea to specify MUSTs (or even SHOULDs) when
taking which error to return. It is ok to say this check MUST be done
(especially if it is security related), but there is no point of
listing the order or specific error codes in all possible places.
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Wed, 2 Sep 2009 11:33:18 -0400

>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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Sep 2009 12:01:27 +0300

David Wierbowski writes:
> This is a lower case must.

Which does not say you can ignore it. It just says it is not protocol
specific "MUST" which affect interoperability, it is behavior "must"
meaning you still need to do that, but even if you don't you will most
likely are still interoperable (altought the connection will/can
fail). 

> I'm not sure it is safe to assume that
> implementations adhere to a lower case must.

I expect that that implementations do follow such text. If
implementations ignore this kind of text with no upper case MUST then
I am sure the implementation doing that is completely broken.

If we take other example from section 1.2 which says:

----------------------------------------------------------------------
   The initial exchanges are as follows:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

   HDR contains the Security Parameter Indexes (SPIs), version numbers,
   and flags of various sorts.  The SAi1 payload states the
   cryptographic algorithms the initiator supports for the IKE SA.  The
   KE payload sends the initiator's Diffie-Hellman value.  Ni is the
   initiator's nonce.
----------------------------------------------------------------------

There is no "MUST/SHOULD/MAY"s in there but if implementation does not
follow the text explaining how initial exchange packet is generated
the implementation does not work.

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

> CRL checking is not cheap and
> usability feature to me.

The you probably want to make change to the current text which says
you must do it...

On the other hand usually you are using certificates from the same CA,
thus when you checking other ends certificate you already fetch the
CRL from the CA and revoke those certificates which are revoked by it.
If that happens yo revoke your own certificate you should notice that
too. That means in normal case the CRL checking is free operation as
you need to do it anyways for the other ends certificate (the most
expensive operation usually is the fetching of the CRL and verifying
its signature, looping through the revoked certificates after that is
very cheap).

Only case where it actually do cost you extra is when you are using
different CRL for your own certificate than what the other end is
using. 

> From the sender's point of view the worst thing

Partially agree on that. Especially as the recipient of your
certificate might have information that you do not (for example the
garage door opener remote controller might not have connection to the
CA to fetch CRLs, but the server to which it connects to can have, and
can check CRLs and can also send CRLs inband to the remote).

But with current text that is not possible. 
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Thu, 3 Sep 2009 10:01:25 -0400

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

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

>The you probably want to make change to the current text which says
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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Sep 2009 11:54:17 +0300

> common sense to the remaining text.

I agree. I have done that myself too, and only noticed that this does
not really help when the latest version of ikev2bis had following
change (this is unrelated to current case, but it is more generic
case):

Old text:
----------------------------------------------------------------------
   The responder can be assured that the initiator is prepared to
   receive messages on an SA if either (1) it has received a
   cryptographically valid message on the new SA, or (2) the new SA
   rekeys an existing SA and it receives an IKE request to close the
   replaced SA.  When rekeying an SA, the responder SHOULD continue to
   send messages on the old SA until one of those events occurs.  
----------------------------------------------------------------------
New text:
----------------------------------------------------------------------
   The responder can be assured that the initiator is prepared to
   receive messages on an SA if either (1) it has received a
   cryptographically valid message on the new SA, or (2) the new SA
   rekeys an existing SA and it receives an IKE request to close the
   replaced SA.  When rekeying an SA, the responder continues to send
   traffic on the old SA until one of those events occurs.  
----------------------------------------------------------------------

Earlier we knew that we didn't follow that SHOULD exactly, as we moved
to use new SA either if old one was deleted or after short timeout. We
knew this was against the SHOULD and changing it was on our todo list.

Now the new text does not say "SHOULD" anymore (it was removed, not
lowercased), it just says you "continue to send traffic on the old SA"
so effectually now it is MUST as it says you do that, you are not
allowed to do anything else.

So when the text removed "SHOULD" it actually made the required
behavior much stricter, and made our old implementations so they do
not follow the given behavior (as this was in our todo list, we have
already changed the code).

This is more generic thing than just CRLs (or rekey behavior), i.e.
what does non-lowercase "do this" statement in the RFC really mean.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Sep 2009 10:15:17 +0300

OK. Let's try this again. Is this acceptable?

2.21.  Error Handling

    There are many kinds of errors that can occur during IKE processing.
    If a request is received that is badly formatted, or unacceptable  
for
    reasons of policy (e.g., no matching cryptographic algorithms), the
    response MUST contain a Notify payload indicating the error.  If an
    error occurs in the processing of a response, then the initiator
    SHOULD initiate an INFORMATIONAL exchange with a Notify payload
    describing the problem.  If an error occurs outside the context of  
an
    IKE request (e.g., the node is getting ESP messages on a nonexistent
    SPI), the node SHOULD initiate an INFORMATIONAL exchange with a
    Notify payload describing the problem.

    Errors that occur before a cryptographically protected IKE SA is
    established must be handled very carefully.  There is a trade-off
    between wanting to be helpful in diagnosing a problem and responding
    to it and wanting to avoid being a dupe in a denial of service  
attack
    based on forged messages.

    If a node receives a message on UDP port 500 or 4500 outside the
    context of an IKE SA known to it (and not a request to start one),  
it
    may be the result of a recent crash of the node.  If the message is
    marked as a response, the node MAY audit the suspicious event but
    MUST NOT respond.  If the message is marked as a request, the node
    MAY audit the suspicious event and MAY send a response.  If a
    response is sent, the response MUST be sent to the IP address and
    port from whence it came with the same IKE SPIs and the Message ID
    copied.  The response MUST NOT be cryptographically protected and
    MUST contain a Notify payload indicating INVALID_IKE_SPI.  The
    INVALID_IKE_SPI notification indicates an IKE message was received
    with an unrecognized destination SPI; this usually indicates that  
the
    recipient has rebooted and forgotten the existence of an IKE SA.

    A node receiving such an unprotected Notify payload MUST NOT respond
    and MUST NOT change the state of any existing SAs.  The message  
might
    be a forgery or might be a response, the genuine correspondent was
    tricked into sending.  A node should treat such a message (and  
also a
    network message like ICMP destination unreachable) as a hint that
    there might be problems with SAs to that IP address and should
    initiate a liveness check for any such IKE SA.  An implementation
    SHOULD limit the frequency of such tests to avoid being tricked into
    participating in a denial of service attack.

    A node receiving a suspicious message from an IP address (and port,
    if NAT traversal is used) with which it has an IKE SA SHOULD send an
    IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
    The recipient MUST NOT change the state of any SAs as a result, but
    may wish to audit the event to aid in diagnosing malfunctions.  A
    node MUST limit the rate at which it will send messages in response
    to unprotected messages.

    All errors that occur in an IKE_AUTH exchange, causing the
    authentication to fail for whatever reason (invalid shared secret,
    invalid ID, untrusted certificate issuer, revoked or expired
    certificate, etc.)  SHOULD result in an AUTHENTICATION_FAILED
    notification.  If the error occurred on the responder, the
    notification is returned in the protected response, and should be  
the
    only payload in that response.  If the error occurs on the  
initiator,
    the notification MAY be returned in a separate INFORMATIONAL
    exchange, usually with no other payloads.  Note, however, that
    messages that contain an unsupported critical payload, or where the
    whole message is malformed (rather than just bad payload contents),
    MUST be rejected in their entirety, and only lead to an
    UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification.  The
    receiver should not verify the payloads related to authentication in
    this case.

    If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
    is established, but establishing the child SA, or requesting
    configuration information may still fail.  This failure does not
    automatically cause the IKE SA to be deleted.  Specifically, a
    responder may include all the payloads associated with  
authentication
    (IDr, Cert and AUTH) while sending error notifications for the
    piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
    NO_PROPOSAL_CHOSEN, etc.), and the initiator MUST NOT fail the
    authentication because of this.  The initiator MAY, of course, for
    reasons of policy later delete such an IKE SA.

    Only authentication failures and malformed messages lead to a
    deletion of the IKE SA without requiring an explicit INFORMATIONAL
    exchange carrying a DELETE payload.  Other error conditions require
    such an exchange, if policy dictates that this is needed.

    In an IKE_SA_INIT exchange, any error notification causes the
    exchange to fail, although some, like COOKIE, INVALID_KE_PAYLOAD or
    INVALID_MAJOR_VERSION may lead to a subsequent successful exchange.
    In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage  
immediately
    following it, only the following notifications cause the IKE SA to  
be
    deleted or not created, without a DELETE payload:
    o  UNSUPPORTED_CRITICAL_PAYLOAD
    o  INVALID_SYNTAX
    o  AUTHENTICATION_FAILED

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Sep 2009 16:41:11 +0300

Yoav Nir writes:
>     describing the problem.

I think MAY is better than SHOULD there, or even forbidding this
completely.

As said before I do not know any implementation which does this now,
and there is also problem that there is no way to correlate the
INFORMATIONAL exchange to the exchange which caused this problem. I.e.
if you have window size 5, and you have 3 CREATE_CHILD_SA exchanges
going, and then you get response to second of them that is invalid and
you send INFORMATIONAL exchange out saying there was something wrong
with the response, then there is no way for the other end to know to
which of those exchanges that INFORMATIONAL related.

Also I do not know any normal cases where it would be useful to send
error message to the response. In some cases it may possible that
initiator will process the response packet, and notice there is
something wrong and do actions. One of the cases is for example when
initiator asked for transport mode, but responder selected tunnel mode
and initiator's policy does not allow tunnel mode. In this example the
current RFC4306 text already says initiator deletes the SA.

Can you give me any example when it would be possible to use this
feature? Note, that this is new requirement that was not in the
RFC4306.

Note, that this also goes against the rule that no response never
generates new requests (it is not explictly mentioned in the IKEv2,
but is still there). This means that if either end has bug that cases
for example the response packet of the INFORMATIONAL exchange causes
other end to send error notification to the other end (using same
broken INFORMATIONAL exchange) then the peers will go to INFORMATIONAL
exchange loop.

Because of the looping problem, and the problem there is no way to
relate new INFORMATIONAL exchange request to the response which
triggered it, I would actually suggest we forbid this situation and
say that errors in response must be handled otherwise (most likely by
deleting the IPsec SA or IKE SA or simply ignoring the error case (if
it does not affect the state of the SAs)).

>     only payload in that response.

When we discussed about the ticket #9 Pasi proposed a text that
explains this case better, i.e. specifying that the "although the
IKE_AUTH messages are encrypted and integrity protected, if the peer
receiving this notification has not authenticated the other end yet,
the information needs to be treated with caution."

http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html

This was supposed to be added to section 1.2, but it is not there.
Perhaps we should add it here instead of 1.2 then (or at least add it
to 1.2 if not here). 

>     exchange, usually with no other payloads.

Here creating new INFORMATIONAL exchanges based on the errors in
response may be allowed as there is no problems with correlating the
message (no other exchanges is allowed before IKE_AUTH finishes), and
there should not problems with loops, as the error notification was
related to the IKE_AUTH not generic stuff.

Also if there was problem when processing IKE_AUTH response, I would
indicate that then the IKE_AUTH didn't finishs, thus we do not have
IKE SA. If the problem was only in the Chid / IPsec SA part of the
exchange then that can be fixed by deleting the IPsec SA.

>     In an IKE_AUTH exchange, or in the INFORMATIONAL exchnage
						        ^^^^^^

Typo. 

>     semantics, but MUST NOT use them unless the peer is known to

This still leaves it bit open what happens if "malformed messages" are
received later for example in CREATE_CHILD_SA exchange, and responder
of the exchange detects that payload is malformed and returns
INVALID_SYNTAX error notification. The last part says that in IKE_AUTH
it will cause sa not to be created, but it does not talk about future
exchanges. On the other hand earlier it says "Only ... malformed
messages lead to a deletion of the IKE SA withotu requiring an
explicit INFORMATIONAL exchange carrying a DELETE payload".

For me that would also indicate that if I get INVALID_SYNTAX (which is
returned if you send malformed messages) then you can silently delete
the IKE SA.

Perhaps we should add new paragraph about that too.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Sep 2009 16:55:48 +0300

> which of those exchanges that INFORMATIONAL related.

Agreed. How about SHOULD, but adding "if the error occurred in the  
response to an IKE_AUTH exchange, and in payloads related to  
authentication. A new exchange SHOULD NOT be triggered for reporting  
errors in child SAs, CFG, or notifications."

> Perhaps we should add new paragraph about that too.

I think that any of these would be fatal to the particular exchange,  
but will not cause a silent discard of the IKE SA.  You might have a  
policy that tells you to delete any IKE SA where you got or sent an  
INVALID_SYNTAX, but because it can also be a policy matter, we  
shouldn't really mandate it.
> -- 
> [email-masked]
>
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Sep 2009 19:13:13 +0300

> errors in child SAs, CFG, or notifications."

If that error occurred during IKE_AUTH because of authentication
failure or INVALID_SYNTAX or similar then there is no way to start new
INFORMATIONAL exchange as for the initiators part the IKE SA wasn't
finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on.

So only place where IKE_AUTH could fail so that you have IKE SA but
you would want to send notification back is that there was something
wrong with the configuration payload or Child SA processing. If there
is something wrong with Child SA processing, then correct way is not
to install the SA, and send delete for the Child SA. If there was
something wrong with the configuration payload processing, then
depending on the situation you might want to delete the IKE SA (if you
didn't get the IP-address at all or similar) or just ignore the error.

I really DO NOT like the idea of triggering new exchanges based on the
failures when parsing the response. In general IKEv2 has been written
so there cannot really be errors on the responder (i.e. traffic
selectors are narrowed based on the initiators proposal, so responder
cannot select something that is not allowed by initiator, and same is
for SAs proposals etc).

Can you give me example where this would be used? I.e. situation where
IKE_AUTH response packet caused error which needs to be communicated
to the other end and which is not related to IKE SA authentication. 

> shouldn't really mandate it.

Our implementation will silently delete IKE SA (i.e do not send DELETE
notification as if state is so messed up that you get INVALID_SYNTAX
errors, then DELETE notification will mostly generate same response)
when it receives INVALID_SYNTAX or after it has sent out
INVALID_SYNTAX as it assumes there is something badly wrong with
either implementation and there is no point of continuing at that
situation. I do not have any plans of changing that, and I think other
implementations do something similar (i.e if you start sending them
properly encrypted and authenticated random garbage they will tear
down the IKE SA).  
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 8 Sep 2009 12:48:00 -0400

Tero,

> finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on.

We've already bent this rule a little bit if the responder detects an 
authentication failure.  I.e., we've documented that the responder should 
encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his 
perspective he doesn't have a valid IKE SA.

It seems reasonable to do something similar in this case.  I.e., if the 
initiator detects an authentication failure (say, the responder's 
certificate has expired), it is reasonable for him to 1) send a protected 
INFORMATIONAL request over the unauthenticated SA with the error notify, 
and 2) disallow any other possible activity on that invalid SA except for 
retransmitting the request and waiting on the response.

In our own case, if this happens as initiator, we will do this, sending a 
protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) 
and also a DELETE for the IKE SA.  In my view the DELETE is actually the 
more crucial payload here, and the Notify payload is primarily a courtesy 
to hint to the responder why the delete is being sent (since there is 
really no way to assert that a Notify in an INFORMATIONAL request relates 
to some other particular exchange).

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

From:
Tero Kivinen <[email-masked]>
To:
Yoav Nir <[email-masked]>
Cc:
"[email-masked] WG" <[email-masked]>
Date:
09/07/2009 12:18 PM
Subject:
Re: [IPsec] Issue #26: Missing treatment of error cases

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Sep 2009 23:26:26 +0300

> perspective he doesn't have a valid IKE SA.

True, but that does not mean the IKE SA is valid, it just means they
do have shared unauthenticated keys for encryption and MAC. I.e that
encrypt & MAC proves that the reply comes back from the same server
who did Diffie-Hellman, but it does not mean it came back from the
correct intended responder. The reply could be generated also by man
in the middle. 

> retransmitting the request and waiting on the response.

That adds quite of lot of special code (i.e you need to make sure that
IKE SA is not used for anything else while you are waiting for reply),
and does not really help that much. This will cause server to clean up
the IKE SA faster than it normally would, but as client initiated this
there is most likely no data coming from the server to client anyways
thus no traffic is really lost.

The client will still fail the IKE SA and as client was the one who
initiated it, it will most likely try again and the user noticing
things does not work tries to fix things. This kind of authentication
failures usually do not go away without user intervention anyways.

>From the responders point of view the IKE SA is there, so he does not
care which way the initiator does, so this is not something that needs
to be defined at all (i.e. there is no need to define whether it is
allowed, recommended or forbidden). Whether implementation does this
can be completely left to as local matter. 

> to some other particular exchange).

You are free to do that.

It will gain you so that server will delete the IKE SA bit earlier
than it would otherwise (i.e. otherwise it would need to wait for the
DPD to kick in (which would most likely happen quite soon, as there is
completely idle IKE and IPsec SA there) and that would then delete the
IKE SA).

For the original users point of view (i.e. the initiator / client)
this does not matter, as he still cannot get connection...

I myself as implementor writing code do not want to add such code to
our product as it is just adding code that is very seldomly run and
even less seldomly tested, and which can contain security bugs, thus
the product is safer and better without such code. But this is just my
own opinion, and other implementors might have different opinions, and
I am ok with text which says you MAY do it. I would object against
SHOULD, and object very strongly against MUST. 
-- 
[email-masked]