Subject: [pcp] Unsolicited Messages to Client with no security association

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 10:39:57 -0500

A PCP server may wish to send an unsolicited message to a specific
client in cases where it has no security association with that client.
This can happen for a number of reasons:

First, the server may never have had a security association with the
client. For example the client may be using unauthenticated PCP. I think
we can ignore that case in the rest of this message. If unauthenticated
PCP was good enough to set up the mapping, it should be good enough for
messages related to the mapping.

Secondly, the security association may have timed out. That is, the MSK
lifetime may have ended.

Another possibility is that the server discarded security state. It's
probably a bad idea for a server to choose to discard security state if
that server sends unsolicited messages. However you can imagine cases
(disconnect request from AAA, administrator action, server policy
changes) where a server discards state. It's important to realize that
especially in the case where servers are sending unsolicited messages to
clients, they are not discarding security state to conserve
resources. PCP is all about maintaining state on the server; the point
of the protocol is to set up and manage state. It seems reasonable for
servers to be able to discard security state for clients when they have
no other state for those clients, but it also seems reasonable for
servers to retain security state while they retain other state.

The simplest thing for the server to do is to send the unsolicited
message without authentication.

So, what should the client do when it receives the message without
authentication? That depends on client policy. Many clients will be able
to act on an unsolicited message even without integrity
protection. Remember these same clients would often be willing to
perform unauthenticated PCP requests; authentication was triggered by
server policy and an error in response to an unauthenticated request.

Some clients may want integrity protection of the unsolicited
message. My interpretation of the sense of the room was that supporting
this is a requirement. The simplest thing for such a client to do is to
go authenticate and to re-issue the request corresponding to the
unsolicited message. As I understand it, unsolicited messages in PCP
directed at a specific client correspond to map or peer responses. The
client can solicit a response to such a map or peer entry by generating
the corresponding authenticated map or peer request.  In this model, the
client decides whether it needs authentication for the unsolicited
message. That's desirable because the client is the one acting on the
information. It's not worth wasting authentication resources if the
client will take no action, is sleeping, is temporarily not on the
network, etc. It's not worth authentication if the client security
policy would be just as happy as with an unauthenticated request. It's
often not worth authentication if an attacker could use unauthenticated
means  such as a TCP RST to accomplish the same goal as the unsolicited
message.
However in some cases, integrity protection may be important; the client
is in a better position to know when that's the case.

Reinaldo has one concern about this approach. An attacker can force a
client that does require authentication to perform needless
authentications simply by injecting false unauthenticated responses. A
way to resolve this is to compute an authentication tag  that basically
says "I threw away your state," using the old MSK  and include this in
an PCP option  in unsolicited messages that are sent. This requires
servers to retain  at least the contents of this option. However, as we
discussed, we're not trying to allow servers to discard security
resources if they retain enough PCP resources to need to send
unsolicited messages. A client receiving this option knows the server
has discarded a security association and knows which association has
been discarded. An attacker could replay this option but gains no
advantage from doing so provided that the server never sends this option
before it actually disables the security association.

Another approach would be to simply retain the MSK past its expiration
and send the standard PCP integrity option. I don't favor this approach
because there are legitimate security reasons for retiring keys and
security associations. It's something the WG could do if it wishes,
although we will probably have to write up a fair bit of security
considerations text explaining the impact and might have some challenges
explaining how we meet the requirements of the EAP keying framework. The
approach of sending an integrity-protected "I deleted the SA," message
is easier to defend from a security standpoint. An implementation that
has strict key lifetime handling--for example one with a hardware
security module that enforces key lifetimes--can pre-compute the message
while the MSK is still valid.

So, in some ways this sounds a lot like server-initiated
re-authentication. The server sends a trigger and later there is a new
authentication. Here are some properties I consider important; other
schemes that meet these properties might also be fine even if they look
even more like server-initiated re-authentication. The biggest one is
that clients can sleep or go away from the network for a period without
disrupting their PCP state or PCP security associations. Clients choose
whether the authentication happens; the server can indicate that
re-authentication is required for future messages to be
integrity-protected, but the client decides whether that protection is
desirable. The client logic for making this decision is PCP-specific;
even if a PANA approach is used, the PCP client rather than the PAC
should decide whether it is desirable to re-authenticate, because only
PCP knows whether the client will act on unsolicited messages or whether
unauthenticated unsolicited messages even open important attack vectors.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 Nov 2012 12:03:05 -0500

On Nov 14, 2012, at 10:39 AM, Sam Hartman wrote:
> authentications simply by injecting false unauthenticated responses.

What is the alternative?  If we support server-originated re-authentication instead, we complicate the operational model of PCP and the server can just do the same thing more directly by sending unneeded re-authenication messages.

Margaret

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 14 Nov 2012 18:03:15 +0000

Hello Margaret,

I believe one of the action items from meeting was for Sam to come up with a proposal which I believe is his previous email in the thread.

Other comments inline…

From: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Date: Wed, 14 Nov 2012 12:03:05 -0500
To: Sam Hartman <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pcp] Unsolicited Messages to Client with no security association

What is the alternative?  If we support server-originated re-authentication instead, we complicate the operational model of PCP

[Reinaldo] Well, these are the trade-off we are looking at. I believe supporting unsolicited messages was the consensus.

and the server can just do the same thing more directly by sending unneeded re-authenication messages.

[Reinaldo] How? Two points for consideration.

1 – Unsolicited messages are not reliable. They need to be retransmitted 3  times, but still, not reliable.
2 - I believe the attack I described is much easier to perform than many other attacks we discussed before.

-RP

Margaret

_______________________________________________ pcp mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pcp

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 13:09:13 -0500

>>>>> "Reinaldo" == Reinaldo Penno (repenno) <[email-masked]> writes:

    Reinaldo> Hello Margaret, I believe one of the action items from
    Reinaldo> meeting was for Sam to come up with a proposal which I
    Reinaldo> believe is his previous email in the thread.

    Reinaldo> Other comments inline?

Right, and note that my original message has (just after where Margaret
stopped quoting) my proposal for how to address both your concern and
hers.

Personally, I don't think attackers forcing a large number of
authentications is a big deal; I think I'd disagree with your
characterization that is easier than other attacks we've been
discussing.  However I also think it's easy to fix so I proposed a fix.

--Sam

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Nov 2012 21:05:58 +0100

Le 2012-11-14 18:03, Margaret Wasserman a écrit :
> What is the alternative?  If we support server-originated
> re-authentication instead, we complicate the operational model of PCP

There are two classes of clients:

A) clients that don't listen to ANNOUNCE
B) clients that listen to ANNOUNCE

If the server sends a re-authentication message to the client, either 
the client ignores it (class A) or is willing and prepared to act on it 
(class B). Why not just send a re-authentication message? The goal is 
not complicating the class A clients. If class A clients are allowed to 
ignore the re-authentication request, then I think it's reasonable to 
expect the class B clients to implement the necessary stuff.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 15:31:36 -0500

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

I was actually thinking more section 14.2 than 14.1, although this
applies to both.

    Simon> If the server sends a re-authentication message to the
    Simon> client, either the client ignores it (class A) or is willing
    Simon> and prepared to act on it (class B). Why not just send a
    Simon> re-authentication message? The goal is not complicating the
    Simon> class A clients. If class A clients are allowed to ignore the
    Simon> re-authentication request, then I think it's reasonable to
    Simon> expect the class B clients to implement the necessary stuff.

First, note that if we use PANA-level server-initiated
re-authentication, the PAC cannot ignore the message according to the
current PANA protocol.

More generally, though, I think there are significant classes of clients
that would benefit from implementing re-authentication but would not
need to integrity protect unsolicited responses.  I'm not worried about
implementation complexity.  I'm more worried about battery life, sleep
states and the like.  I think there are a lot of cases where the client
will want to ignore re-authentication and I want to make it easy to do
that.

I went through the details of why I want to make it easy for clients to
avoid re-authentication of unsolicited messages in my original long
message.  Would you be willing to respond to those specific points if
you disagree after taking a look at them?

--Sam

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Nov 2012 21:51:17 +0100

> I was actually thinking more section 14.2 than 14.1, although this

Right.

> states and the like.

But they're already listening for unsolicited messages from the server. 
How does adding server-initiated re-authentication affect battery life 
or sleep states?

> I think there are a lot of cases where the client

Absolutely.

> you disagree after taking a look at them?

I don't disagree. I just wanted to point out that server-initiated 
re-authentication may be just fine if clients that don't listen to 
unsolicited messages anyway are allowed to ignore it. If I understand 
correctly, this avenue was not explored in your long email.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 16:00:10 -0500

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

    Simon> But they're already listening for unsolicited messages from
    Simon> the server. How does adding server-initiated
    Simon> re-authentication affect battery life or sleep states?

So, first, I can listen to unsolicited messages while awake, and ignore
them while asleep.  If I get to do the same to re-authentication, then I
think re-authentication is not that harmful and I don't have a huge
problem with it.

I'd still like to avoid it.  One reason is that it generates unnecessary
traffic if you don't care about the integrity of unsolicited messages.
Another is that if you happen to be using a credential such as an OTP or
smart card that requires user interaction, it generates unnecessary user
interactions.  Asking the user to type something or insert a smart code
just so you can ignore the integrity check on the resulting unsolicited
message seems highly undesirable to me.

I don't have a huge problem with a "you should consider re-auth now,"
message if it can be ignored by clients.  I'd prefer to piggy-back it as
an option on other unsolicited messages as I described, but I am not
hugely attached to that.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 15 Nov 2012 00:51:29 +0000

>traffic if you don't care about the integrity of unsolicited messages.

I do not believe this would be common case.

If the client started the PCP session using authentication is because

1 - PCP Server only accepts authenticated PCP due to, say,  policy or
2 - The "domain" to which client belongs does not meet simple security
model 

Otherwise, it is much simpler to just use non-authenticated PCP. Therefore
one would 
expect that a client that initiated an authenticated PCP session also
thinks 
it is important to receive authenticated unsolicited messages.  If client
will 
process and a pass to a application is another issue.

Another point to consider. Today unsolicited messages mean
"something went very wrong". But let's suppose in the near future we have
all kinds 
of unsolicited messages. For example, unsolicited description update.
You can have a configuration saying:

- Process all ANNOUNCE and MAPPING Updates unsolicited messages
- Drop everything else

Or even something more fine-grained.

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Nov 2012 20:16:13 -0500

>>>>> "Reinaldo" == Reinaldo Penno (repenno) <[email-masked]> writes:

    Reinaldo> On 11/14/12 4:00 PM, "Sam Hartman" <[email-masked]> wrote:
    Reinaldo> I do not believe this would be common case.

My assumption is the most common case for why a client performs
authentication is that it gets an authentication required error from the
server.  In that case, it is the server, rather than the client that
desires the authentication.

Many such clients will not need to check the integrity of unsolicited
messages.

For the most part, I'd only expect clients that forced authentication
(even for servers that accept unauthenticated requests) to care about
integrity of unsolicited messages.
I agree we need to handle that case.

M y suspicion is that:

1) Most clients/servers will not happen to use authentication even if
they implement it.

2) When clients use authentication it will generally be because the
server insisted on it.

3) A small minority of clients--typically under the direct control of an
administrator or the like--will insist on authentication all the time.
This is the class that cares most about integrity of unsolicited
messages.

I agree with you that future unsolicited messages may have different
integrity profiles. In my mind that's yet another reason to allow the
client to decide how much it cares about being able to authenticate
them.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 15 Nov 2012 01:30:45 +0000

>desires the authentication.

The same reasoning applies. If server thinks authentication is so
important, it follows that
unsolicited messages must be authenticated.

>Many such clients will not need to check the integrity of unsolicited

The client has no way to distinguishing between mapping updates from
regular responses.

---

From: Alper Yegin <[email-masked]>
Date: Sat, 17 Nov 2012 01:46:13 +0200

Folks,

If PCP is operating in authenticated mode, all the messages shall be integrity protected.
Allowing some messages be consumed w/o integrity/replay/origin authentication is does not give us a secure solution. Does anyone disagree?
I don't understand why we should design such a thing. 

I know Sam's desire is to avoid supporting server-initiated re-auth. I don't understand why it's such a big deal that we should consider going with an incomplete security solution.

It's simple. When the server has a message to send to the client, if there's no PCP SA available, the server initiates re-auth and instantiates a PCP SA to send the message securely.
Now, if the client is "sleeping", it won't wake up for auth. Auth will not generate PCP SA, the PCP message will be tossed away (because the PCP server cannot be sending an unsecure PCP message). [Same net effect for the unauthenticated case as well. A sleeping client will not receive the message from the server].

Alper

---

From: Simon Perreault <[email-masked]>
Date: Sun, 18 Nov 2012 10:23:01 +0100

FWIW, I share Alper's understanding fully.

Simon

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2012 07:56:00 -0500

Hi.  First, we've gotten to a point where we agree that clients who will
ignore unsolicited messages from the server can ignore unsolicited
server-initiated re-authentication.

If  we also send the message requesting re-authentication at the time
when the server has an unsolicited message to send, rather than when the
SA expires, then I think we have a solution that does very little harm.
So, if that is what we end up with, I'm OK.
I think it's important to send the authentication solicitation at time
when there's a message to send for two reasons:

1) The client may be absent from the network earlier and may return in
time to receive the unsolicited message. If the client doesn't return,
it will miss both the authentication request and the unsolicited PCP
message, which is fine.

2) We don't waste batteries or resources doing authentication until
we're going to use it.

That said, I believe my proposal is a superior technical solution so I'd
like to go for a couple more rounds of discussion.

    Alper> Folks, If PCP is operating in authenticated mode, all the
    Alper> messages shall be integrity protected.  Allowing some
    Alper> messages be consumed w/o integrity/replay/origin
    Alper> authentication is does not give us a secure solution. Does
    Alper> anyone disagree?  

I disagree.

It kind of misses the point of security analysis to make blanket
statements like "that's secure," or "that's insecure."
Nothing is absolutely secure, and spending resources focused on attacks
that don't matter does not increase security and may decrease security
because of bugs.
As an example, I could go around screaming that all the solutions on the
table are wildly insecure because they don't provide confidentiality
protection for the PCP messages.
Except disclosure of the contents  of PCP messages is not  a
vulnerability in our threat model. So, that's not a weakness under the
threats we care about, so I would be wasting the group's time if I said
that the lack of confidentiality made PCP insecure. 

So, why do we care about authentication and integrity?
Well we'll start  by noting that a lot of the time we don't care about
it at all. We fully expect unauthenticated PCP to be quite common. So
here are the vulnerabilities we seem to be concerned about:

1) Some servers  care about the integrity and origin of requests. The
primary harm in if this security service is not provided to servers that
care about it is  that unauthorized service may be granted, or
availability and integrity of the mappings may be impacted.

2) Some clients care about the origin  and integrity of the
requests they make. If an attacker could modify their requests, then an
attacker could impact availability of the mappings.  I.E. change the
internal port being requested or the like.

3) Some clients care about integrity and origin of the response. If an
attacker could modify the response the attacker could impact
availability and integrity of the mappings. I.E. attacker tells the
client the wrong external address.

So from the above, we get:

R1) Servers MUST be able to indicate that a request will not be
processed without authentication.

R2) Clients MUST be able to request authentication before sending a
request even if the server would accept an unauthenticated request.

R3) A client that sends an authenticated request MUST be able to verify
the integrity and origin of an unsolicited response should it choose to
do so.

However, we don't seem to care about:

z) From the standpoint of the server, nothing seems to care about the
integrity and origin of the response. In particular, I can identify
nothing bad that happens to the server if the unsolicited response is
successfully attacked.

So, the two security folks who have responded disagree with the claim
that its inherently insecure if unsolicited responses to authenticated
requests are sometimes not integrity protected.

Jim pointed out an example of a security application (email
verification) that works that way. While the client Jim worked on didn't
do things that way, I've used several clients that do verify signatures
only on request. Also, services like DNS Security permit clients to
decide whether to verify; as an example the BIND name server has a
configuration option about whether to validate signatures. Many TLS
libraries permit applications to choose whether to verify server
certificates; this is a widely used feature.
So, yes, only verify integrity when you need it is a common security
practice across a wide variety of technologies.

Hope that helps.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 00:06:15 +0900

Sam,

For clients who care about integrity and origin of the response, there 
must be another requirement:

R4)  A server MUST be able to send authenticated unsoliciated response 
if the client requested authentication.

R4 is also required to satisfy R3 so that a client who chooses to verify 
the integrity of and origin of an unsolicited response can do so.

So, you seem to actually agree with Alper.

Or am I missing something?

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2012 10:41:39 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Sam, For clients who care about integrity and origin of
    Yoshihiro> the response, there must be another requirement:

    Yoshihiro> R4) A server MUST be able to send authenticated
    Yoshihiro> unsoliciated response if the client requested
    Yoshihiro> authentication.

    Yoshihiro> R4 is also required to satisfy R3 so that a client who
    Yoshihiro> chooses to verify the integrity of and origin of an
    Yoshihiro> unsolicited response can do so.

I think that  I was too narrow in my statement of R3.

I didn't simply mean that if the response happened to have  a MAC, the
client needed to be able to verify the MAC.

I meant that  a client needs to be able to  follow some procedure for
verifying the integrity and origin of a response if the client chooses
to do so.

Depending on what procedure we pick, that will likely constrain servers.

Your requirement R4  is too broad. For example it's not a requirement
that servers be able to send authenticated unsolicited messages to
clients that will not verify the integrity of those messages.

would you be willing to work with me to restate my requirement R3 to
capture what I'm trying to express in this message?

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 09:32:08 +0900

Sam,

It seems what you suggest is to have a policy to allow unauthenticated 
responses while requests are authenticated even if the client and server 
have agreed to authenticate each other.  I see no benefit of allowing 
such a policy.  It just introduces a DoS attack with false 
re-authentication triggers. Let's not do it.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Nov 2012 21:19:24 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> Sam, It seems what you suggest is to have a policy to
    Yoshihiro> allow unauthenticated responses while requests are
    Yoshihiro> authenticated even if the client and server have agreed
    Yoshihiro> to authenticate each other.  I see no benefit of allowing
    Yoshihiro> such a policy.  It just introduces a DoS attack with
    Yoshihiro> false re-authentication triggers. Let's not do it.

I'm happy to discuss benefits once we agree on a security model.  It
sounds like you believe my statement of Z is wrong or that there's a new
threat to availability with regard to the client.
Can you clearly state that?

In a form similar to how I stated 1-3 and Z?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 30 Nov 2012 12:13:01 +0900

> Can you clearly state that?

False re-authentication triggers sent by an attacker can start 
re-authentication even if neither the client nor the server actually 
wants to re-key.  Note that a client or a server may want to re-key 
independently of each other at any time even before the key lifetime 
expires whenever it thinks that the key is being weak.  As a result, the 
client and server may end up with spending more resources for 
unnecessarily re-authentication exchanges caused by such false 
triggers.   Detecting false re-auth triggers would require the client to 
verify MAC of the re-auth triggers, which can be considered another DoS 
attack, but the DoS is IMO managable and the impact is much smaller than 
going through unnecessarily re-authentications.

Yoshihiro Ohba

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 30 Nov 2012 03:45:39 +0000

One point that I made earlier is that a client can not distinguish between
a regular response and an unsolicited response. Both are exactly the same
from a PCP perspective.

Therefore it is my impression that any proposal that relies on a
distinction between the two needs to define how a client can disambiguate
them. 

One can say that any response received by the client after the first is
unsolicited. This holds true except in the case where the first response
is lost, a change happens in the server which triggers an unsolicited
response. From the client pov this would be the first response.

Thanks,

Reinaldo

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 Nov 2012 09:31:33 +0200

Sam,

Even if what you were saying made sense (which I strongly disagree for the very reasons Yoshi has been explaining), it does not matter. Let me explain:

You are claiming there is a deployment case where unsolicited messages from the server does not need to be integrity-protected.
Nevertheless, there would also be deployment cases where server wants to integrity-protect all of the messages.

Therefore, "the protocol must support integrity-protecting unsolicited messages". 

If your claim were true, we'd simply say "it's the server's policy to decide when to use that or not."
But, nevertheless, protocol has to support it.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Nov 2012 06:58:20 -0500

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> Sam, Even if what you were saying made sense (which I
    Alper> strongly disagree for the very reasons Yoshi has been
    Alper> explaining), it does not matter. Let me explain:

    Alper> You are claiming there is a deployment case where unsolicited
    Alper> messages from the server does not need to be
    Alper> integrity-protected.  Nevertheless, there would also be
    Alper> deployment cases where server wants to integrity-protect all
    Alper> of the messages.

Alper, saying a thing again and again does not make it true.
I claim there is no security reason for a server  to want to integrity
protect all its messages.
That is precisely the disagreement, and asserting your position again
and again  doesn't move the discussion forward.
I've provided you with a framework of threats and security requirements
in which to argue about whether  there is a reason for a server to
require  that responses be integrity protected.
Please construct an argument rather than repeat yourself. If you don't
like my framework, please propose your own.
Alternatively, step aside and let us move on and get some work done.

We both agree that clients need to be able to validate the integrity of
responses.  That means the response either needs to be sent with
integrity, or the client needs to be able to solicit the same
information with integrity protection.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Nov 2012 07:14:26 -0500

>>>>> "Reinaldo" == Reinaldo Penno (repenno) <[email-masked]> writes:

    Reinaldo> One point that I made earlier is that a client can not
    Reinaldo> distinguish between a regular response and an unsolicited
    Reinaldo> response. Both are exactly the same from a PCP
    Reinaldo> perspective.

    Reinaldo> Therefore it is my impression that any proposal that
    Reinaldo> relies on a distinction between the two needs to define
    Reinaldo> how a client can disambiguate them.

I completely agree.
I think clients need to make this distinction anyway in order to
determine whether to retransmit.
I suspect clients will do exactly what you propose in the next
paragraph.

    Reinaldo> One can say that any response received by the client after
    Reinaldo> the first is unsolicited. This holds true except in the
    Reinaldo> case where the first response is lost, a change happens in
    Reinaldo> the server which triggers an unsolicited response. From
    Reinaldo> the client pov this would be the first response.

So, if a response is lost and the client retransmits before the
unsolicited response is generated, then the client will force a new
solicited response.

However, if I'm understanding what you're saying,  there is a corner
case.

t = 0            request sent (retransmit timer fires at t=3)
t = 1            first response sent and lost
t = 2           change triggers unsolicited response

Here  the server thinks it is an unsolicited response and the client
thinks it is solicited.
I agree that solutions must handle this case gracefully.

My proposal handles it as follows.

If the server still has the SA (something we expect to generally be the
case and almost always the case immediately after a request) then it
sends an integrity-protected response at t = 2. The client never
realizes that it was unsolicited; that's totally fine.

If somehow between t = 1 and t =2 the server drops the SA, then it sends
a response that is not integrity protected.  The client desires
integrity so it performs a reauth/resend of the request.

We see here that a server that routinely deletes SAs shortly after
request are received will be anti-social and will decrease client
responsiveness and increase server load. Don't do that:-)

Note that this case  generates the same number of packets as
server-initiated re-authentication. In that mode, at t t = 2, when the
server realizes it has a message to send, it sends a re-auth start
message.
My solution has two key advantages:

A) clients need not perform the re-authentication if they are going to
discard the unsolicited response or otherwise ignore it.

B) The server never needs to queue PCP responses to send. The server
does need to have an EAP request buffer to retransmit the EAP request
during the authentication phase as we discussed at length in another
thread. However, it never needs to have a potentially long queue of
unsolicited responses awaiting security associations to be negotiated.
Clients that care about integrity of unsolicited responses need to maintain a bit more state, but I can think of two
implementation strategies off the top of my head where the client's
state is constant or scales with the number of mappings but not with the
number of unsolicited responses.

--Sam--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 30 Nov 2012 07:19:54 -0500

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> False re-authentication triggers sent by an attacker can
    Yoshihiro> start re-authentication even if neither the client nor
    Yoshihiro> the server actually wants to re-key.  Note that a client
    Yoshihiro> or a server may want to re-key independently of each
    Yoshihiro> other at any time even before the key lifetime expires
    Yoshihiro> whenever it thinks that the key is being weak.  As a
    Yoshihiro> result, the client and server may end up with spending
    Yoshihiro> more resources for unnecessarily re-authentication
    Yoshihiro> exchanges caused by such false triggers.  Detecting false
    Yoshihiro> re-auth triggers would require the client to verify MAC
    Yoshihiro> of the re-auth triggers, which can be considered another
    Yoshihiro> DoS attack, but the DoS is IMO managable and the impact
    Yoshihiro> is much smaller than going through unnecessarily
    Yoshihiro> re-authentications.

OK so,

4) Client and server availability might be impacted if an attacker can
force clients and servers to re-authenticate when neither party actually
desires  re-authentication.

R4) An attacker MUST NOT be able to force the client or server to
perform re-authentication unless the client or server desires
re-authentication.

I think those are both reasonable, and I think they capture the point
you're making.
I'll want to analyze the solutions on the table, but I believe we can
meet R4 for these.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 01 Dec 2012 09:06:18 +0900

> perform re-authentication unless the client or server desires

The text looks like a requirement for an attacker's functionality, but I 
believe that is not your intent.

How about this?

R4) A client and a server MUST be able to detect and ignore false 
re-authentication trigger messages sent by attackers.

Yoshihiro Ohba