> -----Original Message----- > From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] > Sent: Friday, July 10, 2015 9:51 PM > To: Tirumaleswar Reddy (tireddy); Sam Hartman > Cc: draft-ietf-pcp-authentication....@tools.ietf.org; 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:pkyzi...@alum.mit.edu] > >> Sent: Thursday, July 09, 2015 8:26 PM > >> To: Tirumaleswar Reddy (tireddy); Sam Hartman > >> Cc: draft-ietf-pcp-authentication....@tools.ietf.org; 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:hartm...@painless-security.com] > >>>> Sent: Wednesday, July 08, 2015 6:35 AM > >>>> To: Paul Kyzivat > >>>> Cc: Tirumaleswar Reddy (tireddy); draft-ietf-pcp- > >>>> authentication....@tools.ietf.org; 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. > >>> > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
