Hi Paul, Please see inline
> -----Original Message----- > From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu] > Sent: Wednesday, July 08, 2015 12:49 AM > To: Tirumaleswar Reddy (tireddy); draft-ietf-pcp- > authentication....@tools.ietf.org > 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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
