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