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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Paul,

Please see inline

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Wednesday, July 08, 2015 12:49 AM
> To: Tirumaleswar Reddy (tireddy); draft-ietf-pcp-
> [e-mail]
> Cc: General Area Review Team
> 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.
> 
> 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.

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

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

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.

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

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

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.

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

Got it, added new figure.

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