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

[Paul Kyzivat <[e-mail]>]

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

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

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.

- client restarts somewhere within a sequence of PA messages

- server restarted somewhere within a sequence of PA messages

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