Hi Sam,
On 7/7/15 11:24 AM, Sam Hartman wrote:
"Paul" == Paul Kyzivat <pkyzi...@alum.mit.edu> 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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
