On 7/10/15 12:09 AM, Tirumaleswar Reddy (tireddy) wrote:
Hi Paul,
Please see inline
-----Original Message-----
From: Paul Kyzivat [mailto:[email protected]]
Sent: Thursday, July 09, 2015 8:26 PM
To: Tirumaleswar Reddy (tireddy); Sam Hartman
Cc: [email protected]; 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.
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:[email protected]]
Sent: Wednesday, July 08, 2015 6:35 AM
To: Paul Kyzivat
Cc: Tirumaleswar Reddy (tireddy); draft-ietf-pcp-
[email protected]; 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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
