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

[Paul Kyzivat <[e-mail]>]

Hi Tiru,

While the discussion with you and Sam continues on the major points, 
I'll comment here on the others. I'm trimming to just the points I'm 
replying to.

On 7/6/15 10:20 AM, Tirumaleswar Reddy (tireddy) wrote:

>> [EDITORIAL] Also, I'm still troubled by:
>>
>>      From now on, every PCP message within this PA session MUST contain
>>      this session identifier.
>>
>> As I noted previously, this is a truism - it is a restatement of the definition of a
>> PA session. Also, "From now on" seems a bit informal and vague. I still suggest
>> replacing this sentence with:
>>
>>      Subsequent PCP messages are included within this PA session by
>>      attaching an AUTHENTICATION_TAG option containing this session
>>      identifier.
>
> Subsequent PCP messages within the PA session could also be PCP-Auth messages and these messages will not carry the AUTHENTICATION_TAG option. How about saying the following instead:
> NEW:
> Subsequent PCP messages within this PA session MUST contain this session identifier.

That works for me.

>> * Section 3.1.2:
>>
>> [BUG/MAJOR TECHNICAL] (This is my most major concern!!!)
>>
>> The first sentence is:
>>
>>      In the scenario where a PCP server receives a common PCP request
>>      message from a PCP client which needs to be authenticated, the PCP
>>      server can reply with a PA-Server message to initiate a PA session.
>>
>> As I read RFC6887, this cannot be viewed as a response to the common PCP
>> request!!! The PCP client should still be expecting a response to *that* request,
>> containing the same opcode as the request. And it will retry until it gets such a
>> response.
>>
>> Also, if we ignore that, there is no obvious way of matching this response to the
>> request. The matching rules on 6887 require the opcodes to match, and for
>> some opcode-specific matching rules to be applied to the opcode-specific
>> information. (Note that there could be more than one outstanding, and some
>> requests might require authentication while others do not.)
>>
>> The only way I see to make this work with 6887 is:
>> - send an error response to the common PCP message being challenged.
>>     (With the same opcode as the message. Probably with
>>     AUTHENTICATION_REQUIRED as the response code.
>
> NEW:
> In the scenario where a PCP server receives a common PCP request message from a PCP client which needs to be authenticated, the PCP server  rejects the request with a AUTHENTICATION_REQUIRED error code and can reply with a unsolicited PA-Server message to initiate a PA session. The result code field of this PA-Server message is set to AUTHENTICATION_REQUIRED.

OK. So you are explicitly responding to the request as 6887 requires, 
and then following it up with a PA server message to start the 
authentication process.

That seems to work. I guess that means that the client must wait for the 
server to initiate the authentication before it retries the request. 
Normally that should happen "immediately", but from a programming 
perspective the client will probably need to put a timer on that in case 
it doesn't happen.

>> * Also in section 3.1.2:
>>
>> [TECHNICAL] In the following:
>>
>>      The PCP client MUST NOT retry the common PCP request until it
>>      receives AUTHENTICATION_SUCCEEDED result code from the PCP server.
>>
>> Why MUST NOT? ISTM the point is that the request will not succeed outside a
>> PA session.
>
> Yes.
>
>> Presumably you could try it again, but would just get another
>> request to authenticate.
>
> Yup.
>
>> Wouldn't it be better to state that the client may
>> assume that it is fruitless to try that request outside of a PA session?
>
> Yes.
> NEW:
> If the PCP client retries the common request before EAP authentication is successful then it will receive AUTHENTICATION_REQUIRED error code from the PCP server.

OK.

>> [TECHNICAL] And then in:
>>
>>      If a PCP client receives a PA message containing an EAP
>>      Identity request and cannot generate an EAP Identity response
>>      immediately ... the PCP device MUST reply with a PA-Acknowledgement
>>      message ...
>>
>> This only applies the constraint to an EAP Identity request. IIUC, the full EAP
>> negotiation could involve exchange of several EAP messages. I presume this
>> restriction must apply to all the PA Server messages containing EAP messages,
>> not just the Identity request. If that is so, then this sentence needs to be
>> expanded.
>
> Fixed. I don't see a reason for PCP to distinguish b/w EAP identity request and EAP request (and the same goes for EAP identity response and EAP response). Updated draft to use "EAP request" and "EAP response" in all places.

OK.

>> (In general, I find that the text insufficiently explains that the number of
>> messages in the exchange is variable and how that all works.)
>
> The number of messages exchanged depends on the EAP type.

As part of changing from just talking about identity requests and 
responses to general EAP messages and responses, it would be helpful to 
remind the reader that the number of messages used can vary.

>> In the following:
>>
>>      In this approach, PCP client and a PCP server MUST perform a key-
>>      generating EAP method in authentication.  Particularly, a PCP
>>      authentication implementation MUST support EAP-TTLS [RFC5281] and
>>      SHOULD support TEAP [RFC7170].
>>
>> [EDITORIAL] IIUC, this implies that a non-key-generating EAP method MUST
>> NOT be offered, or selected. It would be helpful to point that out.
>
> It is already mentioned in the document that key-generating EAP method MUST be used. Please clarify why the negative case needs to be discussed. I don't see any confusion.

OK, never mind. It isn't important.

>> [TECHNICAL] Then, in the following:
>>
>>      After the EAP authentication, ... the PCP server MUST generate a PCP
>>      SA ... the PCP client needs to generate a PCP SA ...
>>
>> This implies that there is no PCP SA until after the EAP authentication has
>> completed. But Section 4 says:
>>
>>      At the beginning of a PA session, a session MUST generate a PA SA to
>>      maintain its state information during the session.
>>
>> That says that the PCP SA is generated at the beginning of the PA session,
>> which is before the EAP authentication has begun.
>>
>> This inconsistency needs to be resolved. Since the PCP SA state information
>> listed in section 4 includes the session identifier and sequence numbers as well
>> as the security-specific stuff, and since that stuff is needed to maintain the PA
>> session, ISTM that the PCP SA must be generated as specified in section 4, and
>> so section 3.1.3 needs to be updated. For instance, it could say that when the
>> EAP authentication succeeds, then the PCP SA needs to be *updated* with the
>> negotiated keys.
>
> Updated section 3.1.3
> 1) In this case, before sending out the PA-Server message, the PCP server MUST update the PCP SA with the MSK and transport key, and use the derived transport key to generate a digest for the message.
> 2) In addition, the PCP client needs to update the PCP SA with the MSK and transport key, and uses the derived transport key to secure the message.

OK.

>> [TECHNICAL] At the end of that paragraph:
>>
>>      ... If PCP
>>      client sends common PCP request without AUTHENTICATION_TAG option
>>      then the PCP server rejects the request by returning
>>      AUTHENTICATION_REQUIRED result code in the PA-server message.
>>
>> This is new since my prior questions. This effectively says that you have made
>> the design choice that once a PA session has been established on a particular 5-
>> tuple it MUST be used for all further PCP communication between them.
>>
>> If so, then the consequences of that need to be explored. One consequence that
>> comes to my mind is: what if, after establishing a PA session, one of the parties
>> restarts and loses its PCP SA state?
>>
>> If the client lost state, then when it subsequently attempts to send a PCP
>> message it will receive a response indicating AUTHENTICATION-REQUIRED. But
>> it is then expected to use the existing PCP SA session that it has forgotten. Can
>> it attempt to establish a new session, as in section 3.1.1? I can't tell if that will
>> work.
>>
>> Conversely, what if it is the PCP server that loses the PCP SA state? To handle
>> this case I think you need a new response code:
>> UNKNOWN_SESSION_ID, along with procedures for when to send it and what
>> to do when receiving it.
>>
>> Bottom line - there is more to specify here.
>
> NEW:
>     If a PCP server resets or loses the PA SA due to reboot, power
>     failure, or any reason then it sends unsolicited ANNOUNCE Message as
>     explained in section 14.1.3 of [RFC6887] to the PCP client.  The PCP
>     client authenticates with the PCP server again as discussed in
>     Section 3.1.1 and issues new common PCP requests to recreate any lost
>     mapping state.  If the PCP client resets or loses the PA SA due to
>     reboot, power failure, or any reason and sends common PCP request
>     then PCP server rejects the request with AUTHENTICATION_REQUIRED
>     error code and the client authenticates with the server as discussed
>     in Section 3.1.1.

This is being discussed separately.

>> [TECHNICAL] The final (new) paragraph in this section:
>>
>>      It is possible for independent PCP clients on the host to create
>>      multiple PA sessions with the PCP server.  It is RECOMMENDED that
>>      once a PCP client on the host authenticates with the PCP server any
>>      other PCP clients on the host SHOULD be able to reuse the previously
>>      negotiated transport key for integrity protection.
>>
>> is also in response to my earlier comments. It still isn't working for me, for a
>> couple of reasons:
>>
>> First, I don't know what you mean by "independent PCP clients".
>
> "independent PCP clients" means applications on the host using its own PCP software instance responsible for issuing PCP requests to a PCP server, It is explained in RFC 6887.

I already commented a bit on this.
My concern is what happens on a single 5-tuple.
But that is being discussed separately.

>> IIUC this is all
>> in the context of a single client and server over a 5-tuple.
>> The use case I had in mind was for the aspect of the Advanced Threat Model of
>> 6887: "Any implementation that wants to be more permissive in authorizing
>> explicit mappings than it is in authorizing implicit mappings". Notably where
>> implicitly created mappings can be manipulated without authentication, but
>> where other explicit mappings may be manipulated with authentication. So it
>> isn't really different clients, rather it is code for differing purposes within the
>> same client.
>>
>> Second, this paragraph is in conflict with my prior comment about requiring an
>> established PCP SA to be used. After the first such client established a PCP SA,
>> the others wouldn't be able to establish their own.
>
> Other PCP clients on the host can also establish a PCP SA on their own.

As I said elsewhere, this covers a different case than I was getting at.

But this is being discussed on the other thread.

>> * Section 3.3:
>>
>> [TECHNICAL] This section now says:
>>
>>      ... The result
>>      code for PA-Sever message carrying EAP Identity request will be set
>>      to AUTHENTICATION_REQUIRED and PA-Client message carrying EAP
>>      Identity response will be set to AUTHENTICATION_REPLY.
>>
>> This only specifies the response codes used for an EAP Identity request and its
>> EAP response. My comments to section 3.1.3 regarding response codes for
>> other EAP messages apply here as well.
>
> Yes, updated text.
>
> NEW:
>      ... The result
>         code for PA-Sever message carrying EAP request will be set
>         to AUTHENTICATION_REQUIRED and PA-Client message carrying EAP
>         response will be set to AUTHENTICATION_REPLY.

I think you have this cleared up now.

But thinking more about it, ISTM that it might be clearer if 
AUTHENTICATION_REQUIRED was reserved for the response to Common PCP 
messages when authentication is needed, and then add 
AUTHENTICATION_REQUEST for all the PA Server messages carrying EAP messages.

>> I also see a case that isn't mentioned here or elsewhere. The session lifetime is
>> initialized at the successful completion of EAP authentication or re-
>> authentication. It is always selected by the PA server, and is *optionally*
>> communicated to the PA client. There is no specification of what it is set to
>> prior to this, or what it is set to in the client if the server doesn't send the
>> value. ISTM that there ought to be a default value that is established at the
>> time the SA session is established. That then can govern until/unless a new
>> value is chosen by the server and sent to the client.
>
> Good point, modified draft to mandate the use of session lifetime option.

This leaves the lifetime unspecified from the creation of the PA session 
until the eAP negotiation completes.

I guess you are assuming that there is no need for a lifetime during 
that period. At least you don't want it to expire. Certainly any cases 
relevant in this period are rare. It is however important that sessions 
not get "hung" and persist forever. That might happen if one side lost 
state. IIUC, you expect the retransmission policy to keep things moving 
and prevent such a hang. That *might* be right, but I haven't analyzed 
it in detail, so I'm not certain of it.

For instance, suppose authentication has begun, and the client has sent 
a PA-Acknowledgement message, and the server has received it. Then the 
client restarts, forgetting the PA session in progress. And assume it 
has no reason to send further PCP messages. Will the server ever timeout 
this PA session?

>> [TECHNICAL] This section fails to discuss the "glare" case. (Both client and
>> server decide to send RE-AUTHENTICATION at the same time.) A mechanism
>> needs to be specified to recover from this. (The typical mechanism if for both
>> ends to send some distinct error code, and then a deterministic way to choose
>> when to retry so that glare will not recur.)
>
> Even if both PCP client and PCP trigger re-authentication at the same time there is no change in the way EAP messages are exchanged. The PCP server has to send EAP request to the client so that it can re-authenticate. It is mentioned in the last line of Section 3.3
> <snip from Section 3.3>
> The sequence of EAP messages exchanged for re-authentication will not change, regardless of the PCP device triggering re-authentication.
> </snip>

I'm not sure I understand. I guess you are saying is that nothing 
special is needed to handle this case - that no backoff/retry is required.

Maybe you are right. For the client there really is nothing different. 
For the server, there are subtle differences. Normally when the server 
receives a re-authentication request from the client that triggers a 
response. But, if the server has just sent a reauthentication request 
and then the reception of one from the client should *not* trigger 
sending another one.

So I think there is still need for some text that describes what should 
happen.

>> * Section 5.1:
>>
>> [TECHNICAL] My comment on section 3.3 applies here as well.
>
> Fixed.
> The result code for PA-Sever message carrying EAP request MUST be set to AUTHENTICATION_REQUIRED.
> The result code for PA-Client message carrying EAP response MUST be set to AUTHENTICATION_REPLY.

OK.

>> [EDITORIAL/TECHNICAL] This section makes a change to the PCP Common
>> Request Packet Format defined in section 7.1 of RFC6887, by using a portion of
>> the "Reserved" field for an opcode-specific purpose. This should be harmless in
>> operation because recipients of this format are required to ignore this field. But
>> there could be a problem if a future revision of that RFC were to use the same
>> reserved bits for some other purpose, without recognizing the conflict with this
>> draft.
>>
>> At my request during the LC review this document now indicates that it
>> updates RFC6887. But there still is no explicit statement that future assignment
>> of that field could explicitly impact this document. I would suggest explicitly
>> providing a revised version of Figure 2 from RFC6887, such as:
>>
>>         0                   1                   2                   3
>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |  Version = 2  |R|   Opcode    |   Reserved    |  Opcode-      |
>>        |               | |             |               |  specific-info|
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                 Requested Lifetime (32 bits)                  |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                                                               |
>>        |            PCP Client's IP Address (128 bits)                 |
>>        |                                                               |
>>        |                                                               |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        :                                                               :
>>        :             (optional) Opcode-specific information            :
>>        :                                                               :
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        :                                                               :
>>        :             (optional) PCP Options                            :
>>        :                                                               :
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Section 5.1 already has a figure to depict the revised version of the request format.

Section 5.1 has a figure showing the format for requests containing the 
AUTHENTICATION opcode. I'm suggesting something else, in addition to that.

My point is that your change is usage for this one opcode has potential 
future impact on 6887 as a whole. So when saying that this draft updates 
6887 that means that it is changing the format shown in the figure in 
section 7.1 of 6887, for all opcodes.

As it happens, the change is backward compatible, so that no existing 
implementations are affected. But the change might not be forward 
compatible with some possible future extensions/revisions of 6887. That 
is why it is important to make it clear.

>> * Section 6.1:
>>
>> The first paragraph says:
>>
>>      If a PCP SA is generated as the result of a successful EAP
>>      authentication process, every subsequent PCP message within the
>>      session MUST carry an authentication tag which contains the digest of
>>      the PCP message for data origin authentication and integrity
>>      protection.
>>
>> A couple of things about this:
>>
>> [TECHNICAL] As I commented earlier, it seems that the PCP SA state needs to
>> be established before the EAP authentication process is complete. So some
>> other criterion is needed to decide when to start using the PCP SA to generate
>> digests of messages.
>>
>> [NIT] Also "within the session" is unclear. It would be clearer to say "within the
>> PA session".
>
> Fixed the TECHNICAL and Nit comments.
>
> NEW:
> After successful EAP authentication process, every subsequent PCP message within the PA session MUST carry an authentication tag which contains the digest of the PCP message for data origin authentication and integrity protection.

This is part of our other discussion.

>> * Section 6.2:
>>
>> [TECHNICAL] Earlier I raised a question about what happens if one of the PCP
>> devices is reset and loses PA SA state. That impacts this section as well. If the
>> client loses state, then it will discard any messages containing one of the
>> authentication tag options. What will the server do in that situation? It isn't
>> evident to me that the two of them will be able to get into a functional state
>> again. (By doing authentication over again.) That would be bad.
>
> My response to the previous comment on PCP server or PCP client losing the PCP SA should address this comment as well.

Being discussed separately.

>> * Section 7:
>>
>> Thanks, this section is now more readable.
>>
>> [EDITORIAL] Another change would improve it further: create separate
>> subsections for each distinct registry being updated: opcodes, result codes,
>> options. Identify the table within the corresponding section.
>> (The existing subsections for each opcode would then fall within the opcode
>> section.)
>
> The subsections are for each new option. The updated section is in-line with the details that RFC 6887 in section 19.4 has asked new documents to provide.

I won't belabor the point. It isn't that important.

	Thanks,
	Paul