Subject: [pcp] #61: Unsolicited reauthentication

From: "pcp issue tracker" <[email-masked]>
Date: Fri, 19 Oct 2012 21:49:53 -0000

#61: Unsolicited reauthentication

 Would it be desirable to support unsolicited re-authentication?
  – May depend on answer to issue #60 – is there a need to renew
 authentication information when no requests are being issued?

 Or is it preferable to wait until a new mapping request is issued, and
 start a new authentication process then, if needed?

-- 
----------------------------+---------------------------------------------
 Reporter:  margaretw42@…   |      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/61>
pcp <http://tools.ietf.org/pcp/>

---

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

Comment (by dthaler@…):

 From December 2012 webex interim (summary of discussion):

 Should a client need to remain reachable in order to defend/retain its
 mappings?

 Consider case where client periodically goes to sleep but wants the
 mapping to exist whenever it's awake.   Is this scenario important?

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

Ticket URL: <https://etherpad.tools.ietf.org/wg/pcp/trac/ticket/61#comment:1>
pcp <http://tools.ietf.org/pcp/>

---

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

Comment (by dthaler@…):

 Raw notes from Simon from October 2012 webex interim:

 Slide 10: Operational Model
 - PCP is request/response driven by the client with one-way notifications
 from
   server to client.
 Ralph: That makes client implementation much easier.
 Margaret: It also supports going to sleep. With implicit refresh, you need
 to
 send keepalives regularly. With PCP you can create longer lifetimes and go
 to
 sleep for much longer. That's one of the big points of PCP and we don't
 want to
 change that with auth.
 Alper: PANA doesn't require that.
 Margaret: It needs to be documented.
 Alper: I thought you were referring to PANA ping.
 Sam: There is a problem with it being policy: the client implementation
 needs to
 support all options.
 Alper: But the PCP client *has* to stay alive all the time to refresh the
 mapping.
 (general disagreement)
 Sam: How can I make a PCP client and PANA client that are not running all
 the
 time? For example a script that terminates after the request is done.
 Dave: Margaret summarized two examples where PCP client is no longer
 available:
 third-party case, and when you're going to sleep (e.g. laptop).

Ticket URL: <http://etherpad.tools.ietf.org/wg/pcp/trac/ticket/61#comment:2>
pcp <http://tools.ietf.org/pcp/>

---

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

A few comments on this.

We  could really use input from PCP implementors on whether being able to
go to sleep/not always have a PCP implementation responding to network
messages is important.

It would also be very valuable to get input on what AAA technologies
people would use if they implemented PCP authentication.
Here are some things it would be valuable to know:

A) What AAA technologies do products that might include your PCP server
typically support? (RADIUS, Diameter, both, neither?)

B) Would you expect to implement Diameter support for PCP if you
implement PCP authentication?

C) Would you expect to implement RADIUS support if you implement PCP
authentication?

d) Do your products support RADIUS COA (change of authorization) today?

E) Would you expect your PCP implementation to support RADIUS COA  if
you implement PCP authentication?

A few comments on this topic:

1) rather than forcing unsolicited re-authentication a server can simply
discard a PCP SA and   generate an authentication required error on the
next request.
The disadvantage of this is that the next request may take longer to
execute.

2) I've heard the claim that full authentication takes longer than
re-authentication. There are some confusingly named EAP features called
fast reauthentication and the EAP Reauthentication Protocol (ERP) that
do significantly improve performance of subsequent EAP authentications.
I think these performance gains are independent of whether the server
discards a SA.
What's the basis for the claim that re-authentication takes shorter than
full authentication?

3) Server-initiated re-authentication is an optional feature for lower
layers under the existing specifications, including the Diameter EAP
application, which seems to be the only standards-track way to trigger
it.

4) Standard RADIUS does not support server-initiated re-authentication.

5) There's a non-standards-track extension to RADIUS called COA. It
explicitly forbids use of COA for re-authentication.  I haven't found an
IETF-endorsed way to trigger re-authentication from the server for
RADIUS.  It may be that some COA implementations can somehow do this.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 25 Oct 2012 10:34:08 +0300

Sam,

> go to sleep/not always have a PCP implementation responding to network

What is your definition of "sleep"? For the mobile/wireless engineers, sleep is very specific where the mobile terminal practically detaches from the network except for listening to paging beacons. Is this what you mean or something else?

Btw, your questions are not really for "PCP implementors" but for "people building the nodes that are implementing PCP and whole bunch of other stuff". In other words, NAT implementors, Firewall implementers, etc. 

> The disadvantage of this is that the next request may take longer to

What is the advantage?

> application, which seems to be the only standards-track way to trigger

Nope! Please re-read my email. http://www.ietf.org/mail-archive/web/pcp/current/msg02494.html
If you are still not convinced, then please ask DIME + RADEXT + EMU + EAP MLs.
That's where you can get expert opinion on EAP/AAA, not PCP ML.

> 4) Standard RADIUS does not support server-initiated re-authentication.

LEt me copy paste from my http://www.ietf.org/mail-archive/web/pcp/current/msg02494.html email:

"If you look at the table of attributes on page 21, you see the "CoA request" can carry 0+ EAP message.
So, the NAS (PCP client) can receive an asynchronous EAP request from the AAA."

> RADIUS.  It may be that some COA implementations can somehow do this.

Ask RADEXT WG, please. (Not sure why your questions are still only being circulated in PCP only…….)

Alper

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