Subject: [pcp] #62: Client-driven or server-driven auth retransmissions

From: "pcp issue tracker" <[email-masked]>
Date: Fri, 19 Oct 2012 22:09:40 -0000

#62: Client-driven or server-driven auth retransmissions

 Reported by Alper, Margaret, etc.

 PCP is currently a client-initiated request/response protocol with one-way
 notification.   EAP is often server-driven retransmissions.   This
 question centers around either having server-driven retransmissions or how
 to make EAP use client-driven retransmissions.

 Raw notes from Simon from October 2012 webex interim meeting:

 Slide 12: PANA Model
 - Requires server-initiated reauthentication.
 - Optionally to support liveness detection.
 - Tightly coupled.
 Alper: Retransmissions are driven by EAP. Not PANA's choice.
 Sam: No. You can design an EAP lower-layer where retransmissions are done
 by the client.
 Rafa Marin-Lopez: (did not understand)
 Sam: You can remove the reliability in EAP if we choose. Say PCP or PANA
 is responsible for retransmits.
 Rafa: You need retransmission.
 Sam: Yes but it can be done at either layer: EAP or elsewhere.
 Margaret: If we move it to the PCP layer, we can choose to do only
 client-initiated retransmission. Retransmissions don't need to be
 server-generated.
 Alper: You are reinventing ... (did not understand)
 Margaret: Send a description of how PANA can do only client-initiated
 retransmissions.

-- 
----------------------------+---------------------------------------------
 Reporter:  alper.yegin@…   |      Owner:  draft-ietf-pcp-authentication@…
     Type:  defect          |     Status:  new
 Priority:  major           |  Milestone:
Component:  authentication  |    Version:
 Severity:  -               |   Keywords:
----------------------------+---------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/62>
pcp <http://tools.ietf.org/pcp/>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Oct 2012 07:59:28 -0400

Hi.
Yoshi and I have had several rounds of discussing EAp retransmissions in
the ABFAB working group.
My understanding of the situation has improved.

Retransmission of an EAP request will always happen I've been describing
this issue incorrectly when I brought it up in the PCP group.

The question is what is used to trigger retransmissions, not what party
does the retransmission.

The authenticator (PCP server/PAA) has the EAP request packet as part of
security state it maintains.

The question is whether the authenticator has a timer that causes it to
retransmit the request.  That's what the default behavior in EAP is.

Alternatively, the EAP specification (RFC 3748) allows that timer to be
set to infinite.  In that case, the lower layer (PCP or PANA) is taking
responsibility for reliability.

If the lower layer is handling reliability,  then you can use whatever
trigger you like.
You can have a timer on the server.
Alternatively, you can have a timer on the client and retransmit the
request on the server when you receive a duplicate response.

So, no matter what option you pick, the server is required to hold the
state.
The potential advantage of picking client-triggered retransmits is that
it may make it easier to match an existing implementation.

We could really use input from PCP implementations about whether having
the authentication retransmit timer on the client is easier than the
server.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 24 Oct 2012 21:45:02 +0900

Sam,

Your description below did not capture DoS attack issue with 
client-driven retransmission that I mentioned.
It would be fair if you could mention it.

Yoshihiro Ohba

(2012/10/24 20:59), Sam Hartman wrote:
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Oct 2012 08:49:26 -0400

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

    Yoshihiro> Sam, Your description below did not capture DoS attack
    Yoshihiro> issue with client-driven retransmission that I mentioned.
    Yoshihiro> It would be fair if you could mention it.

Agreed, I'm waiting for that discussion to resolve itself then I'll try
and capture where we are.  I explicitly held off on giving an opinion
about the retransmission issue with regard to PCP because I think our
discussion is still open.

--Sam

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Oct 2012 10:29:52 -0400

> the authentication retransmit timer on the client is easier than the

I can't say I understand all the technical details, but here's my view:

Without auth, only PCP clients do retransmissions. Servers only reply to 
packets, so that's less state and load on PCP servers. It would be nice 
if we could keep it the way it is.

My 2¢CAD...

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: Rafa Marin Lopez <[email-masked]>
Date: Thu, 25 Oct 2012 19:48:02 +0200

Hi Simon:

El 24/10/2012, a las 16:29, Simon Perreault escribió:

> Without auth, only PCP clients do retransmissions. Servers only reply to packets, so that's less state and load on PCP servers. It would be nice if we could keep it the way it is.

In any case, the PCP server will have to keep a state since it will have to run an EAP authenticator state machine and a AAA client. Thus, handling a timer should not add too much (or basically nothing), specially when you already have a protocol that does that for you. 

Having said that, as far as I understand it, the side-by-side PANA solution would not touch this behavior you mention in PCP clients and PCP server implementations. At PCP level, retransmissions will work as usual: PCP clients do retransmissions. But performing authentication would be run by a different protocol which is not PCP and which already provides all the functionality required to perform with full guarantees the authentication you need.

In my opinion, using PANA to bootstrap a PCP SA is pretty straight forward. You run PANA, you get a MSK that it is used to derive a key to build the PCP SA. If during the PCP SA life, you need to refresh the key used for that, you need to perform a re-authentication to obtain a new fresh MSK and therefore a fresh PCP SA. Well, you have also that with PANA. When you do not require the key and, therefore, the PCP SA, you can terminate the PANA session and that's all.

Hope this helps.

> Simon

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Sun, 28 Oct 2012 23:27:08 +0200

> retransmit the request.  That's what the default behavior in EAP is.

Right.

> responsibility for reliability.

"EAP Request" needs to be re-transmitted until the EAP authenticator receives a response.
That can be done either by performing the rexmits at the EAP-layer on the EAP authenticator, or
by performing the rexmits at the EAP-lower layer on the EAP authenticator (the infinite timer at the EAP layer case).
Either way it is the "EAP Request" being rexmited by the EAP authenticator (which is the PCP server in this case).

> request on the server when you receive a duplicate response.

In this "reverse the request direction" case of yours, the PCP client needs to rexmit "EAP-Response[i-1]" until it receives the "EAP-Request[i]".
Right?
So, the "PCP server" needs to cache both "EAP-Response[i-1]" and "EAP-Request[i]" at any time. 
If it ever receives the EAP-Response[i-1] again, it'll rexmit the cached EAP-Request[i].
Right?

> it may make it easier to match an existing implementation.

"… to match an existing implementation of PCP" you mean.
With PANA solutions, PANA is the implementation that takes care of rexmits of EAP, hence this has no impact whatsoever on the PCP implementation.
No per-request state is maintained, no timers are set in the PCP implementation for EAP state machine.

> the authentication retransmit timer on the client is easier than the

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sun, 28 Oct 2012 23:31:15 +0200

With EAP-o-PCP, PCP server has to maintain state (as Sam already acknowledged).
PCP server has to cache the EAP-Request, in case the PCP client asks for it again.
In fact, the PCP server even has to cache the previous EAP-Request, so that I can recognize the repeat request.

On the other hand, if authentication is handled by "PANA", PCP server does not concern itself with any of the caching and rexmit timers.