>>>>> "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.
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.
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.
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.
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.
To get this right, it sounds like we need to:
* Describe how the server indicates session state lost
* 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.
* 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.
--Sam
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
