On 7/7/15 2:29 PM, Sam Hartman wrote:
>> 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.
Good point.
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.
OK.
>> 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.
OK. That seems reasonable. To restate:
If the client sends a request within a session, and receives an error
from the server indicating that the server doesn't know of that session,
then the client SHOULD/MUST first request a new session, and only
retransmit the original request after that session is established.
(Corner case: the new authentication fails. Maybe the server reset to
different credentials, that the client doesn't have. Should the client
try the request again, in case it might work without authentication?)
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.
Good.
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.
I think we are aligned here.
>> 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?
Yes, I think so.
I fear it may take some heavy editing to make the document agree with this.
And, the changes may impact the security properties. But that is your
playground!
Thanks,
Paul
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
