>>>>> "Paul" == Paul Kyzivat <pkyzi...@alum.mit.edu> writes:
Paul> Hi Sam,
Paul> 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.
Paul> I had no a priori understanding of what the thinking was on
Paul> this. I was going only be what I could learn by reading the
Paul> document, and wasn't able to discern the intent from the
Paul> document.
Paul> So I at least make a plea that the document be clarified so
Paul> 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.
Paul> Sure. That is certainly an argument for *allowing* all PCP
Paul> requests to be sent over the PA session once one has been
Paul> established.
I think it's an argument for requiring, not just allowing.
That is once you have a session you need to use it.
Because unless you require that the server doesn't know whether a
request is from an attacker or the client.
However, this is all about cases where the session is established.
We're in agreement that many clients will not choose to authenticate
until they are required by the server.
>> 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.
Paul> I looked at the Advanced Threat Model of RFC6887. And I see
Paul> some cases (e.g. "Any implementation that wants to be more
Paul> permissive in authorizing explicit mappings than it is in
Paul> authorizing implicit mappings") where a mixed model might make
Paul> sense. In particular that query/manipulation of implicit
Paul> mappings (or mappings that would be allowed implicitly) might
Paul> not require authentication, while some or all explicit
Paul> mappings that wouldn't be allowed implicitly require
Paul> authentication.
Paul> In that case, authentication might never happen until the
Paul> client requires one of the explicit mappings. It may be that
Paul> user intervention is required for authentication to succeed,
Paul> so it is undesirable to force it before it is needed.
Agreed.
Paul> Of course this is still compatible with requiring all PCP
Paul> messages (except re-authentication) to go over the PA session
Paul> once one has been established.
Agreed.
>> 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.
Paul> IIUC, when a client is first started it may not know if
Paul> authentication will be required. Rather it may learn that only
Paul> by being forced by the server to authenticate. If it then
Paul> reboots, losing its PA SA state, it will be back in the same
Paul> position it was initially. Else you will be forcing it to
Paul> maintain persistent state across reboots.
O, sorry.
Our requirements seem compatible here but we focused on different sides.
You said that when I client discovered a server had lost sessions it
should try the request without reauthentication.
To me that implies the client expects a session.
In that case, I would prefer the client authenticate.
We are in agreement that clients having lost authentication sessions and
not wishing to authenticate before sending a request should just send an
unauthenticated request.
Paul> Surely if it *knows* it can preemptively authenticate. But if
Paul> it doesn't know then things should still work.
I'd say MUST instead of can, but we're basically in agreement here.
MUST because you open up attacks that the software implementor will
typically not be in a position to evaluate if you choose not to
authenticate in the case where you know you lost a session.
(I'd be OK with SHOULD)
We're in agreement though that if you don't know you've lost a session
it needs to 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.
Paul> Re-authentication requires the client and server to both have
Paul> the prior session state. So that path won't work in cases
Paul> where one has forgotten the state.
I was using re-authentication with its English meaning not as a term of
art from the document.
Sorry for the confusion.
With that clarification are we basically on the same page?
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
