Jim: Thanks very much for your detailed review. Please see the comments below. We will respond to your other emails shortly.
On 9/28/12 9:18 PM, "Jim Schaad" <[email protected]<mailto:[email protected]>> wrote: 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? [HZ] RFC5077 does not specify that client can request a new ticket after sending the TLS ticket, if the client is resuming a session using the session ticket, then it cannot request a new session ticket based on resumed session. We will add some language to clarify that it is not allowed. 2. Section 3.3 s/descried/described/ [HZ] Ok. 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? [HZ] Good catch. We will add a sentence similar to peer-ID, where multiple server IDs need to be exported. 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests a restart via a ClientHello and 3) the peer declines to permit the restart to occur. [HZ] We will clarify that EAP-Failure packet will be sent in those cases. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? [HZ] Restart is only allowed for non-fatal alerts, per TLS RFC. "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.", so restart is not desired in this case. We will clarify that restart is only allowed in non-fatal alert cases. 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? [HZ] We will change it to MUST. 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return reflect if the error occurred inside or outside of the TLS tunnel? [HZ] Good catch. We will add some language to clarify dealing with outer packet errors. Something like: 1. If Outer TLVs are wrong, they will be ignored. 2. If others (version, length, flags, etc.) are wrong, the entire EAP packet will be ignored. 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? [HZ] It's the later. How about add "only" in front "after the peer has determined that..."? b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? [HZ] The server remembers that and issues the PAC after its policy is satisfied. We will clarify that. c) What should a peer do if it receives a PAC TLV with an unknown attribute? [HZ] Ignore that. 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the client prior to a certificate being issued. You may or may not then want to add text that says that the subject name(s) in the certificate request need to be checked against the set of authenticated identities prior to the certificate being issued. [HZ] Good point. We will add some that. 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. [HZ] Yes. It covers both cases. We will add language to clarify that. 11. In section 4.1 - I would like to see a discussion that says that the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. [HZ] I think it should work as defined. The start of the Outer TLVs should be derived from the EAP message length and length of the TLS data. 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are two reasons for the question: a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. [HZ] Good catch. We will clarify that. b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to be sent. The entity sending the TLV should know if it marked it as mandatory or not. The NAK is not the same as an Error TLV. [HZ] Agree. A NAK TLV should be sent in this case. We will clarify. 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ [HZ] Yes. We will correct that. 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? [HZ] No. It is mentioned in Section 4.3, Table of TLVs rules. 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. [HZ] That's correct, only one Identity-Type TLV is allowed.The requested Identity type MUST comes with an EAP request or Basic-Password-Auth-Req. If the peer has the requested identity type, it should send back the same identity type TLV in the response. We missed this and will add this clarification. 16. Section 4.2.4 - I don't understand the default in the event that an unknown value is sent in the status field. If there is an ERROR TLV in the message, should I not use that error code rather than change it? [HZ] No. The error code in the Error TLV if being sent with the Result TLV might mean something, but since the peer doesn't understand the Status field, and most likely will not understand the error code. Sending back Unexpected_TLVs_Exchanged error code is probably appropriate. 17. Section 4.2.6 - Do we need a discussion about how to produce/deal with vender specific errors? Do you expect that vender specific TLVs will have an error mechanism built into them to return an error code? [HZ] We expect the vendor TLV will have its own error handling mechanism or use the standard error codes defined. 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? [HZ] Yes. If the mandatory bit is set on the Vendor-Speific TLV, then the peer need to recognize the vendor ID and all combination of the vendor TLVs. The Vendor TLV format is up to the vendor to define, as specified by the current draft. 19. Section 4.2.9 - After reading this, sketching out some scenarios and so forth, I find that I do not like the text and result being pushed here at all. My problems start, in some respects, with the name of the TLV as it does not map to how I would like to see this TLV treated. I would propose the following set of changes: a) The name of the TLV be changed from Request-Action TLV to Provisional-Result TLV [HZ] I am open with the name change, but think Request-Action probably capture the essence better. b) It needs to be made clear that the TLV can be sent from either the server to the peer or the peer to the server. It is my belief that presently it is only sent from the peer to the client and only in response to a successful Result TLV. [HZ] Ok. I agree that we can extend that to be bidirectional and for either success and failure Result TLV. c) The receiving entity MUST process the TLV. [HZ] Ok. d) The processing for the TLV is as follows: i) The entity MAY choose to process (or start?) any of the TLVs that are included in the message. ii) If the entity chooses NOT to process any TLV in the list, the Provisional-Result TLV is treated as a Result TLV with the code "status" iii) If multiple Provisional-Result TLVs are in the body, the session can continue if ANY of TLV in any Provisional-Result TLV is processed. iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is processed, then the most fatal status should be used. If a status is found which is not understood by the entity, then it should be treated as a fatal TLV. [HZ] Ok. The current text allows for the following: The server sends a Success to the peer The peer says please do this or go to fatal The server sends a clear success outside of the tunnel. [HZ] That's not correct. The last exchange in the tunnel should be an agreed upon Result TLV exchange, before the tunnel is torn down and a clear text EAP success is sent. I wonder if the capability needs to be added to say, please start this TLV. So that a server can say, If you don't start a Channel binding TLV, I will make this a failure return code, if you want to start the channel binding TLV then I am open to giving you a success return code. OK - so this is kind of there, but only one value can be placed there. One cannot say do either an EAP negotiation or process this TLV. [HZ] That's true. Only one request. 20. Section 4.2.12.4 - What does it mean to have an I-ID validation enforcement for PAC session renewal? Does it mean that the final message is not sent unless an appropriate ID is presented? Does it have to be an EAP authentication or is password based authentication sufficient? Should a PAC be invalidated on the server side (oops how do you do that) if it a PAC is presented and then the appropriate ID is not given? [HZ] The I-ID in the PAC is used to validate that the correct user is being authenticated and using his PAC. If they don't match, then the authentication will be rejected as if the authentication failed, with the normal flow including the final Result TLV and clear text EAP failure being sent. It can be either the EAP authentication or the password based authentication. The PAC is not invalidated if the I-ID doesn't match the authenticated identity, the authentication will be rejected. 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? [HZ] Yes. 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 [HZ] Ok with me. Any other feedback from the WG? 23. In IANA - Need to add the Request-Action TLV to the list of status codes [HZ] It is included in the Result TLV, Intermediate Result TOV status code registry in the IANA section. I think it makes sense to have the same one. 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a registry? [HZ] Vendor ID per the draft, is the SMI Network Management Private Enterprise Code already managed by IANA. Jim -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alan DeKok Sent: Tuesday, September 25, 2012 8:04 AM To: [email protected]<mailto:[email protected]> Subject: [Emu] Looking for reviewers We'd like to get the final two documents into last call before the next meeting. Therefore, we're looking for reviewers: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Please post reviews to the list. If all goes well, we can get updated documents issued before the next meeting. Thanks to everyone for their help. Alan DeKok. _______________________________________________ Emu mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
