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?
2. Section 3.3 s/descried/described/ 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? 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. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? 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? 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? 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? c) What should a peer do if it receives a PAC TLV with an unknown attribute? 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. 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. 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. 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. 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. 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? 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. 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? 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? 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? 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 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. c) The receiving entity MUST process the TLV. 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. 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. 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. 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? 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 23. In IANA - Need to add the Request-Action TLV to the list of status codes 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a registry? Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alan DeKok > Sent: Tuesday, September 25, 2012 8:04 AM > To: [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] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
