Subject: [IPsec] Cookie logic results in failed authentication

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Sep 2020 17:46:30 +0300

Hi,

while performing stress tests, we ran into the problem, that is concerned with the way cookies are handled in RFC7296.
The problem is that if network conditions are bad (high probability for packets to be delayed, reordered or lost),
then some SAs are not established with AUTHENTICATION_FAILED error. Consider the following scenario:

	Initiator							Responder
1. HDR, SAi, KEi, Ni  -->						
2.								-->	HDR, SAi, KEi, Ni  
									(server has a large number of half-open SAs, so it responds
with cookie,
									that is generated using cookie secret K1)
2. (message is delayed in the network)	...	<--      HDR, N(COOKIE1)
3. (client retransmits its original message)
HDR, SAi, KEi, Ni  -->						
4.								-->	HDR, SAi, KEi, Ni  
									(server has a large number half-open SAs, so it responds
with cookie,
									but the cookie generation secret has been already changed,
and becomes K2,
									that results in generating a new cookie for the same
request, COOKIE2)
5. 								<--      HDR, N(COOKIE2)
6. HDR, N(COOKIE2)   <--
7. (client receives message and retransmits its request with COOKIE2)
HDR, N(COOKIE2), SAi, KEi, Ni    -->
8.								-->	HDR, N(COOKIE2), SAi, KEi, Ni
									(server verifies COOKIE2, it's OK, since K2 is still the
current secret)
9. (message is delayed in the network)	...	<-- 	HDR, SAr, KEr, Nr
10. HDR, N(COOKIE1)   <--
11. (eventually the delayed first message from the server with COOKIE1 reaches the client. Since the client doesn't know 
that COOKIE1 is stall, it decides that it's fresher than COOKIE2, because it receives this message later, so the client replaces
cookie 
and resends its initial request with COOKIE1)
HDR, N(COOKIE1), SAi, KEi, Ni    -->    (this message get lost)
12. HDR, SAr, KEr, Nr   <--
(eventually delayed server's response reaches the client. At this point the client thinks that IKE_SA_INIT is completed and starts
IKE_AUTH)

What is interesting in the above diagram: both the client and the server have eventually completed IKE_SA_INIT,
but they have different opinions on what IKE_SA_INIT message from initiator to responder contains.
The client thinks that the server has responded to its most recently sent message HDR, N(COOKIE1), SAi, KEi, Ni,
while the server has never received it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni. 
As a result - while calculating AUTH payload they will have different inputs to it and authentication will fail.

Despite this diagram looking artificial, we did observe a noticeable number of these errors
during real stress tests (up to 5% of SAs failed with this error in bad network conditions).

What's particularly unfortunate with this:
1. The bad network conditions may happen as a result of DDoS attack, which also may cause cookie logic to be triggered on the
server.
     So, the two pre-conditions - bad network and server under attack are coupled.
2. The most disappointing thing for me is that despite bad network conditions, peers did manage to complete initial IKE exchanges,
     only to get "authentication failed" result.
3. For customers this looks surprising - they have valid credentials, but from time to time they receive "authentication failed"
     diagnostics without any clue why this happens.

The root of the problem is that IKE_SA_INIT request may be retransmitted with different content (different cookies)
and the peers have no means to be sure that they have send/receive identical messages. And later these
possibly different messages are used in AUTH payload calculation. 

I believe that the proper solution would be to exclude cookie from the AUTH payload calculation.
It is verified by the responder using cookie generation secret and it is not concerned with a client 
(the client did not generate it, just echoes it back). However, this solution is obviously 
incompatible with RFC7296, so this is not an option. 

Any opinions? Should this problem be addressed by the WG or ignored?

Regards,
Valery.

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 22 Sep 2020 15:24:31 +0000

Hi Valery,

It seems like a rare scene but I think it needs to be considered.
Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th message? Then when Initiator received the 12th message, it'll know which cookie this message matches with.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
> Sent: Tuesday, September 22, 2020 10:47 PM
> To: IPsecME WG <[email-masked]>
> Subject: [IPsec] Cookie logic results in failed authentication
> 
> Hi,
> 
> while performing stress tests, we ran into the problem, that is concerned
> with the way cookies are handled in RFC7296.
> The problem is that if network conditions are bad (high probability for
> packets to be delayed, reordered or lost), then some SAs are not established
> with AUTHENTICATION_FAILED error. Consider the following scenario:
> 
> 	Initiator							Responder
> 1. HDR, SAi, KEi, Ni  -->
> 2.								-->	HDR, SAi, KEi, Ni
> 									(server has a large number of
> half-open SAs, so it responds with cookie,
> 									(server has a large number
> half-open SAs, so it responds with cookie,
> 									but the cookie generation secret
> has been already changed, and becomes K2,
> 									that results in generating a new
> cookie for the same request, COOKIE2)
> 5. 								<--      HDR, N(COOKIE2)
> 6. HDR, N(COOKIE2)   <--
> 									(server verifies COOKIE2, it's OK,
> since K2 is still the current secret)
> 11. (eventually the delayed first message from the server with COOKIE1
> reaches the client. Since the client doesn't know that COOKIE1 is stall, it
> decides that it's fresher than COOKIE2, because it receives this message later,
> so the client replaces cookie and resends its initial request with COOKIE1)
> (eventually delayed server's response reaches the client. At this point the
> client thinks that IKE_SA_INIT is completed and starts
> IKE_AUTH)
> 
> What is interesting in the above diagram: both the client and the server have
> eventually completed IKE_SA_INIT, but they have different opinions on what
> IKE_SA_INIT message from initiator to responder contains.
> The client thinks that the server has responded to its most recently sent
> message HDR, N(COOKIE1), SAi, KEi, Ni, while the server has never received
> it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni.
> Despite this diagram looking artificial, we did observe a noticeable number
> of these errors during real stress tests (up to 5% of SAs failed with this error
> in bad network conditions).
> 
> 1. The bad network conditions may happen as a result of DDoS attack, which
> also may cause cookie logic to be triggered on the server.
> 2. The most disappointing thing for me is that despite bad network
> conditions, peers did manage to complete initial IKE exchanges,
> 3. For customers this looks surprising - they have valid credentials, but from
> time to time they receive "authentication failed"
> The root of the problem is that IKE_SA_INIT request may be retransmitted
> with different content (different cookies) and the peers have no means to be
> sure that they have send/receive identical messages. And later these possibly
> different messages are used in AUTH payload calculation.
> 
> It is verified by the responder using cookie generation secret and it is not
> concerned with a client (the client did not generate it, just echoes it back).
> However, this solution is obviously incompatible with RFC7296, so this is not
> an option.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2020 21:11:34 +0300

Valery Smyslov writes:
> I believe that the proper solution would be to exclude cookie from
> the AUTH payload calculation. It is verified by the responder using
> cookie generation secret and it is not concerned with a client (the
> client did not generate it, just echoes it back). However, this
> solution is obviously incompatible with RFC7296, so this is not an
> option.

Simple solution. Do not change cookie generation secret too often if
you are under attack with really crappy network... I mean if the
attackers are sending blind connection attemps where cookies help,
changing the cookie does not make any difference. If the attackers are
using real DDoS where each attack packet is actually a host which will
reply to your cookie request then again changing cookie secret does
not help. Only case where changing cookie secret helps is that
attacker cannot collect thousands of valid cookie responsenses and
then suddenly send them all out. 

Or you could try to make sure that the cookie secret selection is
stabile for the same peer always for longer time, i.e. remember some
state that you used cookie secret x for following sessions before
changing to new one. After the cookie secret is changed and enough
time has gone by, you can forget that list and old secret, and you
only need to start collecting that list at the point when you are
planning to change cookie generation secret again soon.

If you have 10000 incoming connections per second and you consider 300
seconds for suitable timeout for sessions to finish, and you only
store source ipv4-address for each time you used cookies, you need 11
MB of memory for that state (and that assumes none of the incoming
sessions are actually coming from same ip-address).

> Any opinions? Should this problem be addressed by the WG or ignored? 

I think the long term solution is to do puzzles, as I do not think you
need to change puzzles secrets that often compared to the cookie
secrets.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2020 21:32:02 +0300

Panwei (William) writes:
> Compared with ignoring cookie payload, how about adding N(COOKIE2)
> in the 9th message? Then when Initiator received the 12th message,
> it'll know which cookie this message matches with.

Actually I think the best option is to include the N(COOKIE) in the
Initiators IKE_AUTH too. I.e.:

   Initiator                         Responder
   -------------------------------------------------------------------
1. HDR(A,0), SAi1, KEi, Ni  -->
2.                       delayed<--  HDR(A,0), N(COOKIE1)
3. HDR(A,0), SAi1, KEi, Ni  -->
4.                              <--  HDR(A,0), N(COOKIE2)
5. HDR(A,0), N(COOKIE2), SAi1,
       KEi, Ni  -->
6. delayed received here
7. HDR(A,0), N(COOKIE1), SAi1,
       KEi, Ni  --> lost
8.                              <--  HDR(A,B), SAr1, KEr,
                                         Nr, [CERTREQ]
9. HDR(A,B), SK {IDi, [CERT,]
       [CERTREQ,] [IDr,] AUTH,
       SAi2, TSi, TSr,
       N(COOKIE1)}  -->
       ^^^^^^^^^^ Added here.
10.                             <--  HDR(A,B), SK {IDr, [CERT,]
                                         AUTH, SAr2, TSi, TSr}

Now when Responder receives IKE_AUTH at step 9, it will decrypt that
and it can see that Initiator thinks the cookie is COOKIE1, and it can
then reconstruct the packets initiator is using for his calculations.
Of course it needs to assume that initiator did not change order of
payloads or anything else when it swiched from COOKIE2 to COOKIE1,
i.e., that only difference in step 5 and step 7 packets is the cookie
payload contents.

This kind of change would most likely be backward compatible, i.e.,
old responders would simply ignore the extra notify payload in
IKE_AUTH and old initiators would not simply even send it.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 23 Sep 2020 17:01:28 +0300

Hi William, 

> Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th message? Then when
> Initiator received the 12th message, it'll know which cookie this message matches with.

The problem with this approach is that the responder doesn't know whether initiator
is a legacy implementation or an updated one. 
The legacy implementation may treat any IKE_SA_INIT response containing COOKIE
as a request to re-send a request with this COOKIE, even it contains other payloads.
So, if the responder includes N(COOKIE) in every IKE_SA_INIT response it will cause 
infinite loop of resending request if initiator is legacy implementation.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 23 Sep 2020 17:13:38 +0300

Hi Tero,

> you are under attack with really crappy network... 

Unfortunately, RFC7296 advises just the opposite:

   The responder should change the value of <secret> frequently, especially
   if under attack.

> I mean if the

I don't like stepping back from stateless to stateful solution (although with a limited state)...
And it doesn't solve the problem completely, it will only occur less frequently.

> need to change puzzles secrets that often compared to the cookie

Puzzle are not solution for this problem. RFC 8019 suggests that 
<AdditionalInfo> is included in the cookie that allows the responder
to determine the requested puzzle difficulties and the like.
Even if cookie secret is not changed, this information may change
quite frequently and we will run into the same problem.

> Initiators IKE_AUTH too. I.e.:
...
> IKE_AUTH and old initiators would not simply even send it.

This change will require both client and server to be updated to take an effect.
IMHO in this case a better option would be as follows: negotiate an extension
that will change AUTH payload input by zeroing out content of cookie.

	Initiator							Responder
HDR, SAi, KEi, Ni  -->						
								<--      HDR, N(COOKIE), N(COOKIE_NA)
HDR, N(COOKIE_NA), SAi, KEi, Ni    -->
								<-- 	HDR, SAr, KEr, Nr

We define a new status notify COOKIE_NA (No Auth). The responder includes
both COOKIE and COOKIE_NA in its response, COOKIE is formed as usual, COOKIE_NA is empty.
If the initiator supports this extension, it includes COOKIE_NA (instead of COOKIE) in the
retried IKE_SA_INIT request, copying a content of COOKIE there.
If the responder receives retried request with COOKIE_NA and successfully verifies it,
later when initiator's AUTH is being verified it just zeroes out the content of COOKIE_NA notification
in the initiator's message passed to prf. The same does the initiator when calculating
AUTH payload.

Comparing with your proposal:
- it consumes less bits on the wire
- it consumes less resources on the responder (no need to verify cookie received in IKE_AUTH)
- it eliminates cases when the responder cannot verify cookie sent in IKE_AUTH (unclear what to do in this case)

The sad thing is that both initiator and responder need to be modified...

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Sep 2020 17:57:38 -0400 (EDT)

> that will change AUTH payload input by zeroing out content of cookie.

What would this actually achieve?

We have a server that is under a serious DDoS attack. It is sending back
COOKIES and soon might have too many half open SA's to even accept any
new connections with COOKIES. Those problems are much more severe than
the legitimate client needing to once retry the overloaded server
because the server changed a cookie secret that should be a rare event
to begin with - in our implementation 1 hour. So the client, which can
do 1 exchange attempt per 10 seconds? Would have a 0.277 % change of
hitting that slot and having another 10s delay for the next keying
attempt to succeed. Is the chance of the DDoS attack plus the chance
of the secret reloading worth a new IKE extension at all?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Sep 2020 03:16:34 +0300

>    The responder should change the value of <secret> frequently, especially

Frequently, as in every hour or so. Not as every few minutes. There is
nothing gained changing the cookie secret too often, as changing it
only protectes against attackers who can do return routability checks.

It only protectes against attackers who are using single or very few
devices to do the attack, and want to collect lots of valid cookies,
and then mount an attack. 

> quite frequently and we will run into the same problem.

If I remember right puzzles requires the attacker to solve the puzzles
before it can do the attack, thus making changing the cookie or puzzle
secrets something that can be done much more infrequently. I mean if
it takes a second for the attacker to solve the puzzle, that means
that you can easly slow the done the attack rate from single source so
much that you do not need to change cookie secret too often.

And if attacker has so much cpu power and with properly connected
routable addresses, that you can't cope even with puzzles on, then you
are out of action anyways, regardless whether you change cookie secret
or not. 

> This change will require both client and server to be updated to

But it is backward compatible with both old and new client and server.
Meaning you can easily just turn it on in your initiator (where this
will be trivial change). Then when responder is supporting this you
will get protection. I agree that implementing this on responder do
require more work. 

> IMHO in this case a better option would be as follows: negotiate an
> extension that will change AUTH payload input by zeroing out content
> of cookie.

Implementing that do require about same amount of work than my
proposal on the responder, but now you again have one more option that
you need to include in IKE_SA_INIT making it even bigger. 

> We define a new status notify COOKIE_NA (No Auth). The responder
> includes both COOKIE and COOKIE_NA in its response, COOKIE is formed
> as usual, COOKIE_NA is empty. If the initiator supports this
> extension, it includes COOKIE_NA (instead of COOKIE) in the retried
> IKE_SA_INIT request, copying a content of COOKIE there. If the
> responder receives retried request with COOKIE_NA and successfully
> verifies it, later when initiator's AUTH is being verified it just
> zeroes out the content of COOKIE_NA notification in the initiator's
> message passed to prf. The same does the initiator when calculating
> AUTH payload.

I think that would work too. I wonder if there is any new attacks
which can be done, because now the cookie is no longer authenticated
at all? I have to think about whether there is something that can be
done when initiator and responder do no longer include cookie in their
auth calculations. In my proposal both would still include the cookie
in calculations so security properties is not changed, responder just
gets informed which cookie was used by initiator.

> - it consumes less bits on the wire

It uses more bits on the wire in the IKE_SA_INIT where it counts. My
proposal does not use any extra bytes there. On the other hand your
proposal uses them in responders cookie reply, where it most likely do
not matter. 

>   cookie received in IKE_AUTH)

Stateless cookie verifications are supposed to be very fast, so I do
not think that is big issue. 

> - it eliminates cases when the responder cannot verify cookie sent
>   in IKE_AUTH (unclear what to do in this case)

If responder cannot verify the cookie, it will drop the conenction
with error, because this cookie was so old that it is no longer
valid... 

> The sad thing is that both initiator and responder need to be

I think that is unavoidable unless you want to do heristics like I
described in other email and keep some state.

Anyways both of these would work, the question is, whether this
problem is big enough that we want to modify the IKEv2 protocol to fix
this. Or whether if we just change cookie secret not to change too
often that will make problem so rare that we do not care.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 24 Sep 2020 16:14:43 +0300

Hi Paul,

> new connections with COOKIES.

I fail to understand why server might have too many half open SA's
with the proposed extension. Note, that it remains stateless until
the client returns COOKIE, exactly as it happens now.

> Those problems are much more severe than

The problem is not the delay. The problem is that sometime 
it caused failed authentication, that definitely must not
happen as a result of bad network. If client receives
fails due to exchange timeout, it's clear for him/her that
this is transient error and an attempt should be retried.
If it receives response AUTHENTICATION_FAILED
it might suspect that something is wrong with his/her credentials 
and probably won't retry until figuring this out.
Even if this happens rarely, it means that the protocol is flawed.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 24 Sep 2020 16:44:28 +0300

Hi Tero,

> much that you do not need to change cookie secret too often.

If the same cookie is returned every time to a given initiator,
then this initiator can solve puzzle once (since cookie is an input data 
for a puzzle) and then present the solution many times (selecting the same
SPIi and Ni), thus bypassing DDoS protection. 

For this reason RFC8019 advises to make every cookie different
or at least to change the secret frequently.

> are out of action anyways, regardless whether you change cookie secret

Not exactly. If you return different cookies to the same initiator each
time it starts creating IKE SA, then this initiator will have to solve
new puzzle every time. Otherwise it can do it once and then 
present the solution many times.

> will get protection. I agree that implementing this on responder do

I didn't say it is not backward compatible :-)

> you need to include in IKE_SA_INIT making it even bigger.

The responder only includes an empty Notify in a COOKIE request message, which
usually contains only N(COOKIE), so it's less than 100 bytes in length.
With my proposal it'll 8 bytes longer. Not a big loss.

> > message passed to prf. The same does the initiator when calculating

I must correct myself. Zeroing out cookie is not enough - 
it must be completely removed from the initiator's message
while performing AUTH computation, as if no cookie was exchanged
(and correct Next Payload and Length in IKE Header). The reason
is that another sequence possible when the server first feels 
it's under attack and returns cookie, but then when the client retransmits
the server can no more feel it is being attacked and returns IKE_SA_INIT
as usual. In this case if packets are reordered and delayed we 
may run into the situation when the client will think cookie was 
requested, but the server will think that it requested no cookie.

> gets informed which cookie was used by initiator.

I hope it leads to no new attacks. Cookie is verified by other means
and if we just have an input to the AUTH as if no cookie 
was exchanged (that is a legitimate case).

> It uses more bits on the wire in the IKE_SA_INIT where it counts. My

8 bytes on the very short message requesting cookie.

> proposal uses them in responders cookie reply, where it most likely do

Usually the size of cookie is about 32-64 bytes, so it'll add 40-72 bytes
to repeat cookie. However, I agree that it's IKE_AUTH when this 
is not a big issue.

> not think that is big issue.

I agree, but you still have to do some work. Comparing to zero work.

> with error, because this cookie was so old that it is no longer

Why? Note, that the purpose of cookie is to verify that the client is 
a live host. If the client managed to get to IKE_AUTH, then it's definitely live.
On the other hand, I agree that it's strange to receive unverifiable 
cookie. That's why I said that it's unclear what to do in this case and I'd rather 
to eliminate such situations from the protocol. 

> often that will make problem so rare that we do not care.

This is the question. 

However, giving the advice from RFC8019 (see above),
it seems that the problem is worth to solve.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Sep 2020 11:37:09 -0400 (EDT)

> the client returns COOKIE, exactly as it happens now.

That's true. I was assuming a bunch of these would be advanced enough
to receive packets back too, but then fail authentication. So they
would linger as half-open for a while. If it was just an attack of
spoofed packets, then you would be correct.

> Even if this happens rarely, it means that the protocol is flawed.

That is a fair point.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 25 Sep 2020 00:50:06 +0300

> SPIi and Ni), thus bypassing DDoS protection. 

But in that case the connection is same, and as puzzle is already
solved, you have created state, and if the IKE_SA_INIT is repeated
with solved puzzle and cookie, you simply retransmit the response. 

Or do you mean that after the few minutes when the actual IKE_AUTH
failes the attacker can then reuse the old cookie and puzzle and try
again, as responder has already forgetten everything about the
previous attempt?

I think adding timestamp to the cookie would allow you to detect when
someone uses old cookie even if you have not changed the cookie
secret, i.e. put unix timestamp inside the AdditionalInfo of the
cookie, and then when you receive cookie with puzzle, you can verify
that it is not too old. 

> or at least to change the secret frequently.

I think adding timestamp is better solution.

> present the solution many times.

If you have timestamps there it can only present it as long as you
allow time for it to solve the puzzle. Also as the time cookies and
puzzles are accepted is limited, you can also keep state of already
used puzzles, as for anything to be added to that state do require
attacker to solve the puzzle first, and you will anyways at least once
move to the IKE_AUTH doing diffie-hellman so you can keep that state
bit longer (for example if you only allow cookies that are sent in
last 5 minutes to be used, that should allow plenty of time for
initiators to solve the puzzle but still allows responder of limited
amount of state it needs to keep (i.e., few bytes for every puzzle
attacker can solve during that time period).

> Why? Note, that the purpose of cookie is to verify that the client
> is a live host. If the client managed to get to IKE_AUTH, then it's
> definitely live. On the other hand, I agree that it's strange to
> receive unverifiable cookie. That's why I said that it's unclear
> what to do in this case and I'd rather to eliminate such situations
> from the protocol.

Because of the cookie is not anything responder ever used, the
authentication will anyways fail, as responder will not be using same
cookie when calculating auth payload than initiator. This is just to
make sure we do not fail with AUTHENTICATION_FAILED but with some
other error message the indicates more clearly that something wierd
happened, and you should try again.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Sep 2020 10:16:20 +0300

Hi Tero,

> again, as responder has already forgetten everything about the

Yes, that's what I meant.

> I think adding timestamp is better solution.

Yes, that's what RFC8019 advises. However, this would make 
the problem with false failed authentication worse, since 
even without changing secret cookies will change frequently
for the same peer and the chances for this situation to happen will increase.

> attacker can solve during that time period).

I'd rather to avoid additional and prolonged states on responder...

> happened, and you should try again.

OK, and that's the problem:. you drop the connection that otherwise 
would succeed just because cookie is stall. Sure, the initiator will retry, 
but overall it looks like a non-optimal protocol design.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 26 Sep 2020 17:52:48 +0300

> for the same peer and the chances for this situation to happen will increase.

Combined with initiator sending the cookie it used in the IKE_SA_INIT
in IKE_AUTH solves that problem, and puzzles solve part of the problem
and the timestamp in cookies solves the saved cookies/puzzles problem. 

> but overall it looks like a non-optimal protocol design.

If initiator sent cookie we do not recognize, that means it is an
attacker, or broken implementation so most likely the authentication
would not work anyways, so no we are not throwing out connection that
would work. Cookie time will tell whether the cookie is new enough
that we should recognize and if cookie time is so old that our policy
does not allow us to accept it, then accepting that cookie is
forbidden by policy.
-- 
[email-masked]