Re: [Gen-art] Gen-ART Telechat review of draft-ietf-pcp-authentication-13.txt

[Paul Kyzivat <[e-mail]>]

Hi Sam,

On 7/7/15 11:24 AM, Sam Hartman wrote:
>>>>>> "Paul" == Paul Kyzivat <[e-mail]> writes:
>
>      Paul> Do you agree with this conclusion? If not, please explain why
>      Paul> you think my logic is wrong.
>
> I partially agree with your conclusion.
> I agree that we need a mechanism to resynchronize state, and I agree
> that unsolicited announces aren't really good enough.
>
> I think it's highly undesirable to permit some requests over a
> five-tuple to be authenticated and some to not be authenticated.

I had no a priori understanding of what the thinking was on this. I was 
going only be what I could learn by reading the document, and wasn't 
able to discern the intent from the document.

So I at least make a plea that the document be clarified so that future 
readers will understand the intended use model.

> You seem to be thinking of authentication as something that tends to
> benefit the server.
> In some deployments that's certainly true.
> However, the client may gain significant benefit from:
>
> * Gaining integrity protection over its communications
>
> * Preventing third-parties from disrupting state it establishes.

Sure. That is certainly an argument for *allowing* all PCP requests to 
be sent over the PA session once one has been established.

> So, for these reasons, I think it's very important that once a session
> is established, only authenticated requests be accepted over that
> five-tuple.

I looked at the Advanced Threat Model of RFC6887. And I see some cases 
(e.g. "Any implementation that wants to be more permissive in 
authorizing explicit mappings than it is in authorizing implicit 
mappings") where a mixed model might make sense. In particular that 
query/manipulation of implicit mappings (or mappings that would be 
allowed implicitly) might not require authentication, while some or all 
explicit mappings that wouldn't be allowed implicitly require 
authentication.

In that case, authentication might never happen until the client 
requires one of the explicit mappings. It may be that user intervention 
is required for authentication to succeed, so it is undesirable to force 
it before it is needed.

Of course this is still compatible with requiring all PCP messages 
(except re-authentication) to go over the PA session once one has been 
established.

> In addition, I think it's desirable that once a session is established,
> a client be expected to re-authenticate if session state is lost, *not*
> to send requests and let the server force re-authentication.

IIUC, when a client is first started it may not know if authentication 
will be required. Rather it may learn that only by being forced by the 
server to authenticate. If it then reboots, losing its PA SA state, it 
will be back in the same position it was initially. Else you will be 
forcing it to maintain persistent state across reboots.

Surely if it *knows* it can preemptively authenticate. But if it doesn't 
know then things should still work.

> However, I do agree with you that we need a mechanism for the server to
> indicate that it has lost state.
> That's only a hint to the client.  Since that indication will not be
> integrity-protected, it may be sent by an attacker.
> A client MAY disregard it, for example if the client suspects a DOS
> attack.  Generally, though a client SHOULD try and re-authenticate,
> discarding the session state only when re-authentication is successful.

Re-authentication requires the client and server to both have the prior 
session state. So that path won't work in cases where one has forgotten 
the state.

> To get this right, it sounds like we need to:
>
> * Describe how the server indicates session state lost

Also what the client does if *it* has lost state (while noting that it 
may not *know* it has lost state as a result of rebooting)

> * Describe what clients do if the client is starting re-authentication
>    but gets a response under the old session.  Presumably this is an
>    indication that an attacker is trying to force re-authentication.

I think we have a terminology issue here. The term "re-authentication" 
has at least two meanings:

1) as currently defined in the document. Doing a new EAP authentication 
under the protection of the prior one, preserving the session id.

2) doing a new EAP authentication when there is no prior PA session, or 
when client or server has no info about it.

I think you must here be using meaning (2).

It would be possible to restructure things so that there is no 
distinction - that the two are handled identically. But I guess there is 
some benefit to using (1) when possible.

> * Describe sufficient server behavior for what our client behavior is to
>    work out well.  That is, if we say that when a client gains evidence
>    the server actually does still have the session, we abandon the
>    re-authentication, we need to make sure servers are still maintaining
>    session state.

Yes.

It is actually hard to describe exactly what is needed in this context. 
Everything needs to hang together consistently and that depends on the 
details.

	Thanks,
	Paul