Subject: [pcp] Server's auth policy discovery

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Oct 2012 11:29:46 +0300

Hello,

Let me compile the auth policy discovery solutions that were discussed on the ML so far.

There are 3 possible auth policies on a PCP server
1. auth not used (not supported, or disabled)
2. use of auth is optional (i.e., PCP Client's decision)
3. auth is mandatory to use

The question is, how does the PCP client know the server's policy.

With the tunneled PANA approach:

The client starts with either unauthenticated PCP or PANA-over-PCP, then observes what it gets back from the server. Either an error, or progress of what it started.

With the port-sharing PANA approach:

PCP client starts without using auth, and observes what happens.
If the server policy is 1 or 2, then PCP works without a problem.
If the server policy is 3, then the PCP server returns an appropriate error message.

Now, coming to Sam's scenario where it is not acceptable for some PCP clients to operate in unauthenticated mode.
He said this is needed for the firewall case.

In that case, DHCP-based discovery needs to be used (irrespective of the auth scenario), as the firewall is not necessarily the first-hop router from PCP Client's perspective.
We can update the DHCP-based discovery solution to deliver "auth policy" of the PCP server along with the "IP address of the server".

In addition to DHCP-based solution, or alternatively, we can define an ANNOUNCE-based single round-trip between the PCP client and PCP server for the client to discover the server's auth policy before proceeding. 

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Oct 2012 06:51:02 -0400

Hi.
As I've mentioned previously, I consider DHCP-based discovery of auth
policy a significant down-side to an approach that requires it.

For many of the same reasons that you want to avoid one port for
authentication and one port for the protocol, you want to avoid one
system for security policy discovery with another system for using that
policy.  Tightly-coupled systems are easier to debug and support.  In
this particular case, if auth policy discovery is in-band, you avoid the
failure modes where the discovery solution has bad information.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Oct 2012 20:07:54 +0900

Is discoverying binary policy (auth unsupported/supported)
is enough, or is discovering three-policy (auth 
unsupported/mandated/optional) needed?

Yoshihiro Ohba

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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Oct 2012 07:35:31 -0400

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

    Yoshihiro> Is discoverying binary policy (auth
    Yoshihiro> unsupported/supported) is enough, or is discovering
    Yoshihiro> three-policy (auth unsupported/mandated/optional) needed?

I think discovering auth supported is sufficient.

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Oct 2012 14:41:29 +0300

Sam,

> I think discovering auth supported is sufficient.

So, you suggest eliminating case 2 below?

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Oct 2012 08:09:40 -0400

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

    Alper> Sam,

    >> I think discovering auth supported is sufficient.

    Alper> So, you suggest eliminating case 2 below?

    Alper> 1. auth not used (not supported, or disabled) 2. use of auth
    Alper> is optional (i.e., PCP Client's decision) 3. auth is
    Alper> mandatory to use

No.  I simply think that if you know whether the server supports auth
then you can avoid sending auth to a server known not to support it,
which is a problem in the PANA port sharing case.

I guess what I should have said is that  if clients who want to use auth
have a way to discover if auth is supported, then I don't think we have
any concerns.

--Sam

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Oct 2012 15:44:28 +0300

Sam,

For a client to decide whether it will use auth or not, it needs to know the server policy.
A server that implements auth does not mean that the client must use auth.
Server may still be configured to allow unauth clients.

This is why I have three distinct cases.

And this I'm asking independent of the PANA port-sharing discussion.

As for dealing with discovery for PANA port-sharing, either:
- We agree that it's OK for all clients to start with "no auth", or
- We use a DHCP-based solution (I know you are not happy with this), or
- We use an ANNOUNCE-based auth policy discovery solution

At least one of these would handle the issue.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Fri, 12 Oct 2012 08:56:35 -0400

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

    Alper> Sam, For a client to decide whether it will use auth or not,
    Alper> it needs to know the server policy.  A server that implements
    Alper> auth does not mean that the client must use auth.  Server may
    Alper> still be configured to allow unauth clients.

    Alper> This is why I have three distinct cases.

I understand that's your model. My model is different, but probably
isomorphic.

    Alper> And this I'm asking independent of the PANA port-sharing
    Alper> discussion.

    Alper> As for dealing with discovery for PANA port-sharing, either:
    Alper> - We agree that it's OK for all clients to start with "no
    Alper> auth", or - We use a DHCP-based solution (I know you are not

Or we have a capability discovery mechanism
or we have a specific opcode for "do you support auth?"

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 12 Oct 2012 08:56:53 -0400

> - We agree that it's OK for all clients to start with "no auth", or

What does this mean?  There are two cases I can think of where a client might "start with" an authenticated request:

1) Where a client is configured to do so.
or
2) Where a client is attempting to renew a mapping that was originally granted via an authenticated request.

How can we say, in either case, that the client should start with "no auth"?

> At least one of these would handle the issue.

I think I am confused about what problem you are trying to solve here...

If a client sends an authenticated request in either of the encapsulated cases (PANA or PCP-Specific), an error will be returned (by the PCP server) indicating (to the PCP client) that the opcode is not supported, and the client will know that authentication is not supported.  If the client is willing to try an unauthenticated request, it can do so at that time.

The only problem that I am aware of is for the demux case, because the error will not be returned to the process that is actually trying to do the authentication (the PANA client_ -- it will go back to the PCP client.  Therefore, the PANA client might keep retrying, even though the PCP server has returned an error.  Also, the PCP client needs to include special handling of the "unsupported version" error that occurs when authentication is being attempted, so that it knows to try an unauthenticated request.  

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Oct 2012 16:28:39 +0300

> How can we say, in either case, that the client should start with "no auth"?

Let me expand on it.
A client that does not know the server's authentication policy needs to discover the server's policy.
One of the ways to achieve that discovery (as there are two others below) is for such client to send an unauthenticated PCP request and see what happens.
If the server accepts that request (i.e., no auth error is returned), then client now knows this server allows unauthenticated PCP requests.
If the server returns an auth error, then now the client knows this server does not allow unauthenticated PCP requests.

> The only problem that I am aware of is for the demux case, because the error will not be returned to the process that is actually trying to do the authentication (the PANA client_ -- it will go bac…

This is the issue we are addressing with the 3 approaches I enumerated.

Alper