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> Hi Sam,
    Paul> On 7/7/15 11:24 AM, Sam Hartman wrote:
    >>>>>>> "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.

    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?