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

[Sam Hartman <[e-mail]>]

>>>>> "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.

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