Subject: [pcp] #60: Loosely coupled vs. tightly coupled authentication

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

#60: Loosely coupled vs. tightly coupled authentication

 Loosely coupled:
  – Authentication needed only at the time of a request, to create/modify a
 mapping.
  – Authorization done separately, using the same mechanism as in non-
 authenticated PCP
   • Mappings are removed when authorization is revoked
  – Mapping lifetime is not tied to authentication lifetime
 Tightly coupled:
  – Authentication and authorization are performed using the same
 mechanism, or there is a link between them
  – Mapping lifetime is tied to authentication lifetime
   • Mappings are removed when keys expire OR authorization is revoke

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

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

---

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

Comment (by dthaler@…):

 Raw notes from Simon in December 2012 webex interim meeting:

 - Authentication and authorization can be loosely or tightly coupled.
 (slide 8)
 Alper: Are there examples of loosely/tightly coupled? All current designs
 are
 tightly coupled.
 Sam: SSH into a router, create a hole in the firewall. The hole will
 extend
 beyond the lifetime of the SSH session. Other example: Kerberos
 certificate ...
 (did not understand).
 Alper: Lifetime of SSH credentials cannot be shorter than the change
 you're
 making on the firewall.
 Margaret: That's not true. Even getting rid of the user does not remove
 the
 firewall changes.
 Margaret: Third party use case: make port 80 go to a web server that does
 not
 speak PCP using third-party client. You don't want to tie the mapping
 lifetime
 to the third-party client.
 Alper: You're referring to PANA ping?
 Margaret: PANA ping and server-initiated have the same effect.
 Sam: (did not understand)
 Margaret: The question is do we want the mapping lifetime to be tied to
 the
 authentication lifetime?
 Dave Thaler: The question is what model do we want? Tightly or loosely
 coupled,
 or both? A protocol could support both and be negotiated per session.
 Margaret: (did not understand)
 Alper: What would be different for the loosely coupled model?
 Margaret: Authentication would only be verified for the act of creating a
 mapping. Not for keeping the keeping the mapping alive.
 Alper: You would receive two separate timers from the AAA server?
 Sam: Not necessarily.
 Dave Thaler: PCP is an additional way of doing things. Does not change NAT
 implementations.
 Alper: AAA server determines lifetime?
 Dave Thaler: It can be independent.
 (I am missing the point of this discussion now.)
 Yoshi: What happens in a loosely coupled system when auth lifetime
 expires?
 Margaret: Authentication procedure is re-done to recreate auth
 credentials.
 Alper: No need to maintain the keys throughout the PCP session?
 Margaret: Right.
 Dave Thaler: PCP session only lasts for 3 seconds or so.
 Alper: PCP is used to maintain mapping state. That's what I call session
 state.
 Margaret: PCP is used to control a firewall or a NAT.
 Sam: (did not understand)
 Simon: A mapping can be created explicitly (PCP) and then refreshed
 implicitly
 (by traffic) indefinitly.
 Alper: How do we know if a client is authorized to modify another client's
 mapping?
 Sam: Server policy.
 Sam: (did not understand)
 Yoshi: Any approach can support loosely or tightly coupled model.
 (general agreement)
 Margaret: We have to specify the coupling model in the document.
 (general agreement)

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

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

---

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

Comment (by dthaler@…):

 Summary of additional discussion from October 2012 webex interim meeting:

 Consider case of THIRD_PARTY where the PCP client is a different entity
 (e.g. web portal) from the node for which the mapping exists.

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Oct 2012 09:30:53 -0400

>     • Mappings are removed when keys expire OR authorization is revoke

May I start a thread about this?

 From the interim discussion, it appears clear to me that we need 
loosely coupled auth.

I don't know if we need tightly coupled auth in addition. So far I can't 
think of any use case for it.

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: Alper Yegin <[email-masked]>
Date: Tue, 23 Oct 2012 11:15:07 +0300

On Oct 22, 2012, at 4:30 PM, Simon Perreault wrote:

> From the interim discussion, it appears clear to me that we need loosely coupled auth.
> 
> I don't know if we need tightly coupled auth in addition. So far I can't think of any use case for it.
> 

Hi,
Comments on http://www.ietf.org/mail-archive/web/pcp/current/msg02474.html would be appreciated.
We need to go deeper into why we want it certain way and what it means in terms of authentication and authorization.
I captured those aspects in that aforementioned email.

Alper

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Oct 2012 09:18:58 -0400

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

    Simon> Le 2012-10-19 17:47, pcp issue tracker a écrit :
    >> Loosely coupled: – Authentication needed only at the
    >> time of a request, to create/modify a mapping.  –
    >> Authorization done separately, using the same mechanism as in
    >> non- authenticated PCP • Mappings are removed when
    >> authorization is revoked – Mapping lifetime is not
    >> tied to authentication lifetime Tightly coupled: –
    >> Authentication and authorization are performed using the same
    >> mechanism, or there is a link between them – Mapping
    >> lifetime is tied to authentication lifetime • Mappings
    >> are removed when keys expire OR authorization is revoke

    Simon> May I start a thread about this?

    Simon> From the interim discussion, it appears clear to me that we
    Simon> need loosely coupled auth.

I also support loosely coupled auth as a strong requirement for PCP.

    Simon> I don't know if we need tightly coupled auth in addition. So
    Simon> far I can't think of any use case for it.

I can't really think of a use case for tightly coupled auth in PCP
either.
However, I'm reasonably sure that you can implement tightly-coupled auth
entirely in terms of existing PCP facilities and loosly coupled auth.

Here's how.

1) A server is free to base mapping lifetimes on the authentication
lifetime.
If it does, then it  can communicate those lifetimes to the client in
PCP responses.

2) If a server chooses to bind authentication lifetime to mapping
lifetime then a client will begin to try and reset the mappings halfway
through their lifetime. The server has an option at that point.  It can
either ask the client to re-authenticate or renew with the existing
lifetime. Presumably if it renews at the existing lifetime the client
will try to renew the mapping at 75% of the original lifetime.
By that point it seems like a server that wants to bind authentication
lifetime to mapping lifetime should force a re-authentication. When the
server forces the re-authentication the lifetime will be extended
assuming the re-authentication is successful and the lifetime coming
back from AAA is extended.  (If AAA is clamping down the lifetime
because for example the account is expiring, then the lifetime is a hard
limit and nothing will increase it.)

The above is enough to support RADIUS without COA, which is a fairly
common deployment. 

COA allows a RADIUS server to change the authorization after the
fact. For example, a RADIUS server can decrease the authorization
lifetime.
PCP supports that too; a PCP server can send an update to an existing
mapping.
Not all clients will respond to that.
That's an explicit decision of PCP. If we wanted we could have (or could
mandate for the future) that clients MUST support and process ongoing
updates from the server. Right now, I believe that's a SHOULD.
However COA is at best a MAY; I'm fairly sure that for RADIUS it is not
even a standards-track protocol.
So, I think that PCP's decisions in this space are similar to the AAA
community's. Some environments need COA, we're going to have the feature
present, but some deployments will be entirely fine without it.

So, existing PCP mechanisms are sufficient for plain RADIUS and for
RADIUS with COA.
Diameter has another feature: server-initiated re-authentication.
That's its own issue so I'll respond there.

My conclusion though is that the PCP layer already supports all the
things you'd need for tightly coupled auth. I don't think we want to
rip that out of PCP. So, I think it is better to support this
functionality at only one layer.  For that reason I strongly prefer that
we support this functionality using the existing mechanisms for
implementations that find it useful. I prefer that we have no explicit
tightly-coupled auth support in our authentication protocol or in PCP,
because I believe it is redundant to existing functionality and overly
complex.