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

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

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Friday, July 10, 2015 9:51 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/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.

Good point, updated new section to use unicast ANNOUNCE to check if the PCP server has lost the state or not.

-Tiru

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