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

[Paul Kyzivat <[e-mail]>]

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