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

[Paul Kyzivat <[e-mail]>]

On 7/10/15 12:09 AM, Tirumaleswar Reddy (tireddy) wrote:
> Hi Paul,
>
> Please see inline
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Thursday, July 09, 2015 8:26 PM
>> To: Tirumaleswar Reddy (tireddy); Sam Hartman
>> Cc: [e-mail]; General Area Review Team
>> Subject: Re: Gen-ART Telechat review of draft-ietf-pcp-authentication-13.txt
>>
>> On 7/8/15 7:20 AM, Tirumaleswar Reddy (tireddy) wrote:
>>> I agree with the discussion and propose the following text to address the
>> comments.
>>>
>>> NEW:
>>
>> Where?
>>
>> I suspect there is need of another document section, or even a larger
>> reorganization, to fit this in with all the other changes we have discussed. (I
>> think at the moment it is becoming a patchwork.)
>
> Yes, I have added a new section called "Recovery from lost PA session".

Sounds good.

>>>      If a PCP server resets or loses the PCP SA due to reboot, power
>>>      failure, or any reason then it sends unsolicited ANNOUNCE response as
>>>      explained in section 14.1.3 of [RFC6887] to the PCP client.  Upon
>>>      receiving the ANNOUNCE response with an anomalous Epoch time, PCP
>>>      client deduces that the server may have lost state.
>>
>> I had forgotten about the Epoch time logic. That does provide a tool to
>> facilitate discovering loss of sync.
>>
>>>      PCP client sends
>>>      re-authentication request to the PCP server to check if the PCP
>>>      server has indeed lost the state or an attacker has sent the ANNOUNCE
>>>      response.  If the response from the PCP server is integrity-protected
>>>      then PCP client discards the re-authentication process
>>
>> How do you go about *discarding* the re-authentication process once it has
>> begun? I don't see any mechanism for doing that.
>
> The client can stop the re-authentication process anytime and it won't impact the PCP SA as long as the session lifetime has not expired. What problem do you see with this approach ?

IIUC client and server each have an implied state machine for handling 
received PA messages based on their response code. But it is only 
implied, so there is little specification of error conditions, such as 
receipt of a message with a response code that is unexpected in that state.

If you just stop in some intermediate state, the other side will be 
stuck in that state until it receives another PA message on the 5-tuple. 
Depending on where things stopped, it might retransmit the last message. 
And you are then depending on the implementation being happy if 
re-authentication starts over from the beginning at some later time.

I think it would improve the chanced for interoperability if you 
included explicit specification of those state machines, with all the 
transitions. (One state machine for the client, another for the server.)

>> The simple solution is to just go ahead and complete the re-authentication.
>> However this does open a DoS attack path.
>>
>> A cleaner way would be for the client to send some sort of NO-OP request
>> within the session. That then could complete or fail.
>>
>>>      and the PCP
>>>      server MUST NOT delete the PCP SA.  If the PCP server responds to the
>>>      re-authentication request with UNKNOWN_SESSION_ID error code then
>> the
>>>      PCP client MUST discard the re-authentication process and initiate
>>>      full EAP authentication with the PCP server as explained in
>>>      Section 3.1.1.  After EAP authentication is successful PCP client
>>>      updates the PCP SA and issues new common PCP requests to recreate any
>>>      lost mapping state.  In a scenario where the PCP server has lost the
>>>      PCP SA but did not inform the PCP client, if the PCP client sends PCP
>>>      request integrity-protected then the PCP server rejects the request
>>>      with UNKNOWN_SESSION_ID error code.  The PCP client then initiates
>>>      full EAP authentication with the PCP server as explained in
>>>      Section 3.1.1 and updates the PCP SA after successful authentication.
>>>
>>>      If the PCP client resets or loses the PCP SA due to reboot, power
>>>      failure, or any reason and sends common PCP request then the PCP
>>>      server rejects the request with AUTHENTICATION_REQUIRED error code.
>>>      The PCP client MUST authenticate with the PCP server and after
>>>      EAP authentication is successful retry  the common PCP request with
>>>      AUTHENTICATION_TAG option.  The PCP server MUST update the
>>>      PCP SA after successful EAP authentication.
>>
>> The rest of this all seems to work.
>
> Thanks.
>
>>
>> But I think there is need for more analysis of what happens if client or server
>> restarts at special points in exchanges. For instance:
>>
>> - client sends Common PCP request within a session then restarts before
>> receiving the response.
>
> If the endpoint reboots then application triggering the PCP request would also have re-started and would not care about the PCP request/response. After the application restarts it would trigger new PCP request.

OK, I guess so for this one. The restarted client may receive the 
response, but would presumably ignore it because of an unknown session id.

>> - client restarts somewhere within a sequence of PA messages
>
> After restart PCP client would do EAP authentication as discussed in section 3.1.1. PCP server should have  idle timer to delete PCP SA if there is no response from the PCP client (for example to also handle a case if the client has detached from the network).

It *might* do that. Or it might start using unauthenticated PCP, until 
it gets a response forcing it to authenticate.

But what does the server do? Various things might happen depending on 
where it was in the sequence. Certainly it will go wrong one way or 
another. The state machine I mentioned above would help clarify this.

>> - server restarted somewhere within a sequence of PA messages
>
> PCP server would reject the PA-Client message with UNKNOWN_SESSION_ID because it has lost state.

Yup.

I have the feeling that you are answering my questions based on an 
implementation. If so, it is a good thing to have such an implementation 
to validate the spec. But that doesn't mean that other implementations 
will behave the same way, unless the spec is sufficiently precise about 
the details.

	Thanks,
	Paul

> Cheers,
> -Tiru
>
>>
>> I haven't thought through all of those. They may not need any special attention,
>> but I bet at least one of them does.
>>
>> 	Thanks,
>> 	Paul
>>
>>> -Tiru
>>>
>>>> -----Original Message-----
>>>> From: Sam Hartman [mailto:[e-mail]]
>>>> Sent: Wednesday, July 08, 2015 6:35 AM
>>>> To: Paul Kyzivat
>>>> Cc: Tirumaleswar Reddy (tireddy); draft-ietf-pcp-
>>>> [e-mail]; General Area Review Team
>>>> Subject: Re: Gen-ART Telechat review of
>>>> draft-ietf-pcp-authentication-13.txt
>>>>
>>>> Yes.
>>>> At this point I think you and I understand what we're talking about.
>>>>
>>>> I haven't been involved in this doc in a while.
>>>> I think we need to let Tirumaleswar comment as well as get feedback
>>>> from the rest of the group.
>>>> Some of this may have been discussed in the WG while I was not
>>>> watching, and you and I have been intentionally abstract.
>>>>
>>>> Unless you and I have both missed something obvious it seems unlikely
>>>> we'll be done with this issue by the telechat.
>>>>
>>>> I am attending the Prague IETF and would be happy to spend
>>>> significant cycles that week wordsmithing/discussing this issue with
>>>> PCP folks if we don't clear before then.
>>>
>
>