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

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Jul 2015 17:53:55 -0400

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

This draft is on the right track but has open issues, described in this 
review.

I've opted to organize my comments in document order. I have tagged 
different comments as BUG/TECHNICAL/EDITORIAL/NIT/etc.

I had difficultly creating my earlier last call review because in a 
number of places I could not discern the intent of the draft. This 
revised version has mostly resolved that problem, and allowed me to be 
more concrete in my comments. I do still have a number of remaining 
concerns.

Disclaimer: I do not claim to be a security expert. The authors are 
vastly more qualified than I on security matters. So I have not tried to 
discern if there are technical security holes in this specification.

     Thanks,
     Paul Kyzivat

* Section 3.1:

[EDITORIAL] In the following sentence:

    ... In the
    message, the Session ID and Sequence Number fields of the
    AUTHENTICATION Opcode are set as 0.

those fields are not not part of the *AUTHENTICATION opcode*. I suggest 
replacing this with:

    In the opcode-specific information of the message, the Session ID
    and Sequence Number fields are set as 0.

[TECHICAL/EDITORIAL] Then, in:

    The PA-Client message SHOULD
    also contain a NONCE option defined in Section 5.3 which consists of
    a random nonce.

Why is this SHOULD rather than MUST? Are there cases where it is 
acceptable to omit the nonce? If so, I would like to see the text 
explain the reasons for and consequences of omitting it, and give 
example(s) of those cases.

[TECHNICAL] The next paragraph calls for the assignment of a *random* 
session identifier. Does it need to be random? Isn't the real 
requirement simply that it be unique from all other sessions between 
this client and server? (I'm guessing that it would be more appropriate 
to replace "random" with "unique", but the key is to achieve whatever 
properties are required for this protocol.)

[EDITORIAL] This paragraph also refers to fields of the opcode. I 
suggest the following replacement:

OLD:
    ... and
    fill the identifier into the Session ID field of the AUTHENTICATION
    Opcode in the PA-Server message.  The Sequence Number field of the
    AUTHENTICATION Opcode is set as 0.

NEW:
    ... and fill the identifier into the Session ID field in the
    server-specific information of the PA-Server message.  The Sequence
    Number field of the message is set as 0.

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

If you instead mean that once a PCP SA has been established then all PCP 
messages must be sent within this PA session, then you need some 
different words. I talk about this more below.

[EDITORIAL] In the figure in this section (and also in 3.1.2) it would 
be very helpful if you showed the response code for each of the PA 
messages. E.g.

      PCP                                                PCP
      client                                            server
        |-- PA-Initiation-------------------------------->|
        |   (Seq=0, Session ID=0, rc=INITIATION)          |
        |                                                 |
        |<-- PA-Server -----------------------------------|
        |    (Seq=0, Session ID=X, EAP Identity request)  |
        |    (rc=AUTHENTICATION_REQUIRED)                 |
        |                                                 |
        |-- PA-Client ----------------------------------->|
        |    (Seq=1, Session ID=X, EAP Identity response) |
        |    (rc=AUTHENTICATION_REPLY)                    |
        |                                                 |
        |<-- PA-Server -----------------------------------|
        |    (Seq=1, Session ID=X, EAP Identity request)  |
        |    (rc=???)                 |

[TECHNICAL] Note that I find no formal specification of what the return 
code must be in the PA messages following the EAP Identity request and 
its reply. (Hence the ??? above.)

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

- To include the new session identifier in that response, use an
   option. The AUTHENTICATION_TAG option seems to work for this.

- Then the client could initiate authentication via PA messages.
   This could be just like in 3.1.1, or perhaps be optimized in some
   way.

If this isn't an acceptable resolution, then it seems necessary for you 
to revise the general PCP response processing in section 8.3 of RFC6887. 
And that would be ugly.

* 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. Presumably you could try it again, but would just 
get another request to authenticate. 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?

* Section 3.1.3:

[TECHNICAL] The following:

    Therefore, after sending out a PA-Server message, the PCP
    server will not send a new PA-Server message until it receives a PA-
    Client message with a proper sequence number from the PCP client, and
    vice versa.

seems overly constrained. AFAICT this only needs to be true within one 
PA session. If there happens to be another PA session, then this 
wouldn't have to apply to messages there. So perhaps this could be 
stated as:

    Therefore, after sending out a PA-Server message, the PCP
    server will not send a new PA-Server message in the same PA session
    until it receives a PA-Client message with a proper sequence number
    from the PCP client, and vice versa.

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

(In general, I find that the text insufficiently explains that the 
number of messages in the exchange is variable and how that all works.)

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.

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

[NIT] Also in that paragraph:

    ... From then on, all the PCP
    messages within the session are secured with the transport key and
    the MAC algorithm specified in the PCP SA, unless a re-authentication
    is performed.

ISTM the exception in case of re-authentication is unnecessary.  The PA 
message exchanges used to perform the re-authentication are secured that 
way, and once the re-authentication is complete, the PCP SA is updated 
with the new keys, and then subsequent messages continue to be secured 
with using the info in the PCP SA.

So I think you can simplify this sentence by omitting the part starting 
with ", unless".

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

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

* Section 3.2:

(This section is much improved. Thanks.)

[EDITORIAL/TECHNICAL] I still have one comment on:

    ... Upon receiving a
    termination-indicating message, the PCP client MUST respond with a
    termination-indicating PA message, and SHOULD then remove the
    associated PA SA.

Why *SHOULD* remove? ISTM this ought to be MUST. Is there any case where 
not removing it is a reasonable thing to do?

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

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.

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

* Section 4:

This section starts with:

    At the beginning of a PA session, a session MUST generate a PA SA to
    maintain its state information during the session.

[EDITORIAL] There is no such term as PA SA. Rather it is PCP SA.

[EDITORIAL] I don't know what it means for a *session* to generate a PA 
SA. I think maybe you mean:

    At the beginning of a new PA session, each PCP device must create
    and initialize state information for a new PA Security Association
    (PCP SA) to maintain its state information for the duration of the
    PA session.

* Section 5.1:

[TECHNICAL] My comment on section 3.3 applies here as well.

[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.5:

[EDITORIAL NIT] For consistency with the others, the section heading for 
this section ought to be "PA_AUTHENTICATION_TAG Option".

[EDITORIAL] Also, "because such information is provided in the 
AUTHENTICATION Opcode" ought to be: "because such information is 
provided in the Opcode-specific information".

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

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

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

This concludes my Gen-ART comments.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 6 Jul 2015 14:20:39 +0000

Hi Paul,

Please see inline

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, July 06, 2015 3:24 AM
> To: [email-masked]
> Cc: General Area Review Team
> Subject: Gen-ART Telechat review of draft-ietf-pcp-authentication-13.txt
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at <​
> Please wait for direction from your document shepherd or AD before posting a
> new version of the draft.
> 
> This draft is on the right track but has open issues, described in this review.
> 
> I've opted to organize my comments in document order. I have tagged different
> comments as BUG/TECHNICAL/EDITORIAL/NIT/etc.
> 
> I had difficultly creating my earlier last call review because in a number of
> places I could not discern the intent of the draft. This revised version has mostly
> resolved that problem, and allowed me to be more concrete in my comments. I
> do still have a number of remaining concerns.
> 
> Disclaimer: I do not claim to be a security expert. The authors are vastly more
> qualified than I on security matters. So I have not tried to discern if there are
> technical security holes in this specification.
> 
>      Thanks,
>      Paul Kyzivat
> 
> * Section 3.1:
> 

Updated.

> Why is this SHOULD rather than MUST? Are there cases where it is acceptable
> to omit the nonce? 

It is not acceptable to omit the nonce, changed from SHOULD to MUST.

> If so, I would like to see the text explain the reasons for and
> consequences of omitting it, and give
> session identifier. Does it need to be random? Isn't the real requirement simply
> that it be unique from all other sessions between this client and server? (I'm
> guessing that it would be more appropriate to replace "random" with "unique",
> but the key is to achieve whatever properties are required for this protocol.)

Replaced "random" with "unique".

> 
> [EDITORIAL] This paragraph also refers to fields of the opcode. I suggest the
> following replacement:
> 
> OLD:
>     ... and

NEW:
and fill the identifier into the Session ID field in the opcode-specific information of the PA-Server message.
The Sequence Number field of the message is set as 0.

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

> messages must be sent within this PA session, then you need some different
> words. I talk about this more below.
> 
> [EDITORIAL] In the figure in this section (and also in 3.1.2) it would be very
> helpful if you showed the response code for each of the PA messages. E.g.
> 
>       PCP                                                PCP
>       client                                            server
> [TECHNICAL] Note that I find no formal specification of what the return code
> must be in the PA messages following the EAP Identity request and its reply.
> (Hence the ??? above.)

Updated figure. EAP request and responses will also use the same return codes as EAP identity request and response.

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

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.

> If this isn't an acceptable resolution, then it seems necessary for you to revise
> the general PCP response processing in section 8.3 of RFC6887.
> And that would be ugly.
> 
> * Also in section 3.1.2:
> 
> 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.

> seems overly constrained. AFAICT this only needs to be true within one PA
> session. If there happens to be another PA session, then this wouldn't have to
> apply to messages there. So perhaps this could be stated as:
> 

Thanks, updated draft.

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

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

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

> This implies that there is no PCP SA until after the EAP authentication has
> completed. But Section 4 says:
> 
> 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.

> way, and once the re-authentication is complete, the PCP SA is updated with
> the new keys, and then subsequent messages continue to be secured with using
> the info in the PCP SA.
> 
> So I think you can simplify this sentence by omitting the part starting with ",
> unless".

Updated.

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

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.

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

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

> not removing it is a reasonable thing to do?

Agreed, changed to MUST.

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

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

> [EDITORIAL] There is no such term as PA SA. Rather it is PCP SA.

Fixed.

> 
> [EDITORIAL] I don't know what it means for a *session* to generate a PA SA. I
> think maybe you mean:
> 

Updated.

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

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

Section 5.1 already has a figure to depict the revised version of the request format.

> 
> 
> * Section 5.5:
> 
> [EDITORIAL NIT] For consistency with the others, the section heading for this
> section ought to be "PA_AUTHENTICATION_TAG Option".

Updated.

> AUTHENTICATION Opcode" ought to be: "because such information is provided
> in the Opcode-specific information".

Updated.

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

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

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

> This concludes my Gen-ART comments.

Thanks for the detailed review.

Cheers,
-Tiru

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 10:51:10 -0400

Hi Tiru,

Before responding to you in detail about the draft text, I think we need 
to resolve some general mechanism issues.

You responded to my questions about multiple PA sessions by saying that 
a host can have several independent PCP clients, and described in 
RFC6887. But that misses my point. As 6887 describes, such independent 
PCP clients will have unique source port numbers. My concern was for 
multiple PA sessions over a single 5-tuple. I gather it is your intent 
that any given 5-tuple either has a PA session or not, and if it does, 
then all PCP messages are to be sent within that PA session. Is that 
right? (ISTM that this assumption is unnecessary, and leads to 
difficulties, but if that is what you have decided then I can accept it.)

If so, that then leads to the problem when one side or the other loses 
the PA SA state. So there must be must be a way to resynchronize after 
that happens.

Having the server use unsolicited ANNOUNCE after reboot to solve the 
problem isn't a complete solution. The server does not necessarily know 
all the destinations that such an announcement needs to be sent. While 
using multicast is a partial solution to that, it won't be a complete 
solution either.

To completely solve that problem I think there must be provision for a 
client that is unaware of any PA session to successfully send PCP 
requests to a server that thinks there is a PA session, and 
reauthenticate if necessary.

Similarly, there must be provision for a client to send a request within 
a PA session and get a response from the server that this PA session is 
unknown. When that happens, the client would need to discard that PA 
session and retry the the request without one. And *then* the server 
could force the client to authenticate again, creating a new PA session 
and PA SA.

Do you agree with this conclusion? If not, please explain why you think 
my logic is wrong.

	Thanks,
	Paul

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Jul 2015 11:24:43 -0400

>>>>> "Paul" == Paul Kyzivat <[email-masked]> writes:

    Paul> Do you agree with this conclusion? If not, please explain why
    Paul> you think my logic is wrong.

I partially agree with your conclusion.
I agree that we need a mechanism to resynchronize state, and I agree
that unsolicited announces aren't really good enough.

I think it's highly undesirable to permit some requests over a
five-tuple to be authenticated and some to not be authenticated.

You seem to be thinking of authentication as something that tends to
benefit the server.
In some deployments that's certainly true.
However, the client may gain significant benefit from:

* Gaining integrity protection over its communications

* Preventing third-parties from disrupting state it establishes.

So, for these reasons, I think it's very important that once a session
is established, only authenticated requests be accepted over that
five-tuple.

In addition, I think it's desirable that once a session is established,
a client be expected to re-authenticate if session state is lost, *not*
to send requests and let the server force re-authentication.

However, I do agree with you that we need a mechanism for the server to
indicate that it has lost state.
That's only a hint to the client.  Since that indication will not be
integrity-protected, it may be sent by an attacker.
A client MAY disregard it, for example if the client suspects a DOS
attack.  Generally, though a client SHOULD try and re-authenticate,
discarding the session state only when re-authentication is successful.

To get this right, it sounds like we need to:

* Describe how the server indicates session state lost

* Describe what clients do if the client is starting re-authentication
  but gets a response under the old session.  Presumably this is an
  indication that an attacker is trying to force re-authentication.

* Describe sufficient server behavior for what our client behavior is to
  work out well.  That is, if we say that when a client gains evidence
  the server actually does still have the session, we abandon the
  re-authentication, we need to make sure servers are still maintaining
  session state.

--Sam

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 14:10:59 -0400

Hi Sam,

> five-tuple to be authenticated and some to not be authenticated.

I had no a priori understanding of what the thinking was on this. I was 
going only be what I could learn by reading the document, and wasn't 
able to discern the intent from the document.

So I at least make a plea that the document be clarified so that future 
readers will understand the intended use model.

> * Preventing third-parties from disrupting state it establishes.

Sure. That is certainly an argument for *allowing* all PCP requests to 
be sent over the PA session once one has been established.

> is established, only authenticated requests be accepted over that

I looked at the Advanced Threat Model of RFC6887. And I see some cases 
(e.g. "Any implementation that wants to be more permissive in 
authorizing explicit mappings than it is in authorizing implicit 
mappings") where a mixed model might make sense. In particular that 
query/manipulation of implicit mappings (or mappings that would be 
allowed implicitly) might not require authentication, while some or all 
explicit mappings that wouldn't be allowed implicitly require 
authentication.

In that case, authentication might never happen until the client 
requires one of the explicit mappings. It may be that user intervention 
is required for authentication to succeed, so it is undesirable to force 
it before it is needed.

Of course this is still compatible with requiring all PCP messages 
(except re-authentication) to go over the PA session once one has been 
established.

> to send requests and let the server force re-authentication.

IIUC, when a client is first started it may not know if authentication 
will be required. Rather it may learn that only by being forced by the 
server to authenticate. If it then reboots, losing its PA SA state, it 
will be back in the same position it was initially. Else you will be 
forcing it to maintain persistent state across reboots.

Surely if it *knows* it can preemptively authenticate. But if it doesn't 
know then things should still work.

> discarding the session state only when re-authentication is successful.

Re-authentication requires the client and server to both have the prior 
session state. So that path won't work in cases where one has forgotten 
the state.

> * Describe how the server indicates session state lost

Also what the client does if *it* has lost state (while noting that it 
may not *know* it has lost state as a result of rebooting)

>    indication that an attacker is trying to force re-authentication.

I think we have a terminology issue here. The term "re-authentication" 
has at least two meanings:

1) as currently defined in the document. Doing a new EAP authentication 
under the protection of the prior one, preserving the session id.

2) doing a new EAP authentication when there is no prior PA session, or 
when client or server has no info about it.

I think you must here be using meaning (2).

It would be possible to restructure things so that there is no 
distinction - that the two are handled identically. But I guess there is 
some benefit to using (1) when possible.

Yes.

It is actually hard to describe exactly what is needed in this context. 
Everything needs to hang together consistently and that depends on the 
details.

	Thanks,
	Paul

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Jul 2015 14:29:10 -0400

>>>>> "Paul" == Paul Kyzivat <[email-masked]> writes:

    Paul> Hi Sam,
    >> 
    >> I partially agree with your conclusion.  I agree that we need a
    >> mechanism to resynchronize state, and I agree that unsolicited
    >> announces aren't really good enough.
    >> 

    Paul> I had no a priori understanding of what the thinking was on
    Paul> this. I was going only be what I could learn by reading the
    Paul> document, and wasn't able to discern the intent from the
    Paul> document.

    Paul> So I at least make a plea that the document be clarified so
    Paul> that future readers will understand the intended use model.

    >> You seem to be thinking of authentication as something that tends
    >> to benefit the server.  In some deployments that's certainly
    >> true.  However, the client may gain significant benefit from:
    >> 

    Paul> Sure. That is certainly an argument for *allowing* all PCP
    Paul> requests to be sent over the PA session once one has been
    Paul> established.

I think it's an argument for requiring, not just allowing.
That is once you have a session you need to use it.
Because unless you require that the server doesn't know whether a
request is from an attacker or the client.
However, this is all about cases where the session is established.
We're in agreement that many clients will not choose to authenticate
until they  are required by the server.

    >> So, for these reasons, I think it's very important that once a
    >> session is established, only authenticated requests be accepted
    >> over that five-tuple.

    Paul> I looked at the Advanced Threat Model of RFC6887. And I see
    Paul> some cases (e.g. "Any implementation that wants to be more
    Paul> permissive in authorizing explicit mappings than it is in
    Paul> authorizing implicit mappings") where a mixed model might make
    Paul> sense. In particular that query/manipulation of implicit
    Paul> mappings (or mappings that would be allowed implicitly) might
    Paul> not require authentication, while some or all explicit
    Paul> mappings that wouldn't be allowed implicitly require
    Paul> authentication.

    Paul> In that case, authentication might never happen until the
    Paul> client requires one of the explicit mappings. It may be that
    Paul> user intervention is required for authentication to succeed,
    Paul> so it is undesirable to force it before it is needed.

Agreed.

    Paul> Of course this is still compatible with requiring all PCP
    Paul> messages (except re-authentication) to go over the PA session
    Paul> once one has been established.
Agreed.

    >> In addition, I think it's desirable that once a session is
    >> established, a client be expected to re-authenticate if session
    >> state is lost, *not* to send requests and let the server force
    >> re-authentication.

    Paul> IIUC, when a client is first started it may not know if
    Paul> authentication will be required. Rather it may learn that only
    Paul> by being forced by the server to authenticate. If it then
    Paul> reboots, losing its PA SA state, it will be back in the same
    Paul> position it was initially. Else you will be forcing it to
    Paul> maintain persistent state across reboots.

O, sorry.
Our requirements seem compatible here but we focused on different sides.

You said that when I client discovered a server had lost sessions it
should try the request without reauthentication.
To me that implies the client expects a session.
In that case, I would prefer the client authenticate.

We are in agreement that clients having lost authentication sessions and
not wishing to authenticate before sending a request should just send an
unauthenticated request.

    Paul> Surely if it *knows* it can preemptively authenticate. But if
    Paul> it doesn't know then things should still work.

I'd say MUST instead of can, but we're basically in agreement here.
MUST because you open up attacks that the software implementor will
typically not be in a position to evaluate if you choose not to
authenticate in the case where you know you lost a session.
(I'd be OK with SHOULD)
We're in agreement though that if you don't know you've lost a session
it needs to still work.

    >> However, I do agree with you that we need a mechanism for the
    >> server to indicate that it has lost state.  That's only a hint to
    >> the client.  Since that indication will not be
    >> integrity-protected, it may be sent by an attacker.  A client MAY
    >> disregard it, for example if the client suspects a DOS attack.
    >> Generally, though a client SHOULD try and re-authenticate,

    Paul> Re-authentication requires the client and server to both have
    Paul> the prior session state. So that path won't work in cases
    Paul> where one has forgotten the state.

I was using re-authentication with its English meaning not as a term of
art from the document.
Sorry for the confusion.
With that clarification are we basically on the same page?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 15:19:04 -0400

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.

> Subsequent PCP messages within this PA session MUST contain this session identifier.

That works for me.

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

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.

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

> 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 "E…

OK.

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

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

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

>     error code and the client authenticates with the server as discussed

This is being discussed separately.

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

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

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

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

> The sequence of EAP messages exchanged for re-authentication will not change, regardless of the PCP device triggering re-authentication.

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.

> The result code for PA-Client message carrying EAP response MUST be set to AUTHENTICATION_REPLY.

OK.

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

> 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 authent…

This is part of our other discussion.

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 15:41:23 -0400

> request is from an attacker or the client.

Good point.

OK.

> In that case, I would prefer the client authenticate.

OK. That seems reasonable. To restate:

If the client sends a request within a session, and receives an error 
from the server indicating that the server doesn't know of that session, 
then the client SHOULD/MUST first request a new session, and only 
retransmit the original request after that session is established.

(Corner case: the new authentication fails. Maybe the server reset to 
different credentials, that the client doesn't have. Should the client 
try the request again, in case it might work without authentication?)

> not wishing to authenticate before sending a request should just send an

Good.

> We're in agreement though that if you don't know you've lost a session

I think we are aligned here.

> With that clarification are we basically on the same page?

Yes, I think so.

I fear it may take some heavy editing to make the document agree with this.

And, the changes may impact the security properties. But that is your 
playground!

	Thanks,
	Paul

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Jul 2015 21:04:44 -0400

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 21:45:06 -0400

> I think we need to let Tirumaleswar comment as well as get feedback from

The main think I have been bringing to this is a fresh perspective, 
without any preconceptions about what the document is trying to say.

I agree it would benefit from further discussion among all the 
contributors to the document.

> we'll be done with this issue by the telechat.

Yeah. That seems likely.

> cycles that week wordsmithing/discussing this issue with PCP folks if we

I won't be in Prague. It seems I have become an emeritus participant. 
But I'll be available remotely. (Though early in the day Prague time 
would be tough for me.)

	Thanks,
	Paul

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Jul 2015 06:07:00 +0000

Hi Paul,

Please see inline

> Sent: Wednesday, July 08, 2015 12:49 AM
> To: Tirumaleswar Reddy (tireddy); draft-ietf-pcp-
> [email-masked]
> Subject: Re: Gen-ART Telechat review of draft-ietf-pcp-authentication-13.txt
> 
> 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.
> 
> >> 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 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:
> >> 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.
> >>
> >> 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.)
> >>
> > 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.
> perspective the client will probably need to put a timer on that in case it
> doesn't happen.
> 
> >> * Also in section 3.1.2:
> >>
> >> outside a PA session.
> >> 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:
> >>
> >> 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.
> 
> 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.

NEW:
The number of EAP messages exchanged between the PCP client and PCP server depends on the EAP method used for authentication.

> >> [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.
> 
> >> This implies that there is no PCP SA until after the EAP
> >> authentication has completed. But Section 4 says:
> >>
> >> 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.
> 
> >> 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
> >> 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.
> >>
> >> is also in response to my earlier comments. It still isn't working
> >> for me, for a couple of reasons:
> >>
> > "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.
> 
> >> Model of
> >> 6887: "Any implementation that wants to be more permissive in
> >> 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.
> >>
> >> 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.
> >
> >> 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

Yes, updated draft.
NEW:
TBA AUTHENTICATION_REQUIRED: The error response is signaled to the client that EAP authentication is required.
TBA AUTHENTICATION_REQUEST:  The server indication to the client that EAP request is signaled in the PA message.

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

PCP server and PCP client should have some have some timer logic to delete incomplete PA sessions. Do we need to discuss about it in the draft ?

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

NEW:
If the PCP server receives re-authentication request from the PCP client after it had signaled re-authentication request then it should discard its request and respond to the re-authentication request from the PCP client.

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

Got it, added new figure.

-Tiru
> >> [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".
> >
> > 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.
> 
> >> [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.
> 
> >> opcode
> > 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.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 8 Jul 2015 11:20:56 +0000

I agree with the discussion and propose the following text to address the comments.

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

-Tiru

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, July 08, 2015 6:35 AM
> To: Paul Kyzivat
> Cc: Tirumaleswar Reddy (tireddy); draft-ietf-pcp-
> [email-masked]; General Area Review Team
> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Jul 2015 10:55:52 -0400

> I agree with the discussion and propose the following text to address the comments.

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

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

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