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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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

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

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

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

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