Sam and Josh, I apologize; I have been going through unsent mail and other files where I make comments. I had actually done most of a review, but had not completed it and therefore had not sent the review to the list. I thought it was out but was in error, thus my earlier message.
Jim 1. In section 1.2, under what circumstances would an acceptor fail to respond to an initiator short of a transport failure? Can this ever happen in a success case? If it cannot then I would suggest that /acceptor may respond/ be changed to /acceptor responds/ I guess there would also be a question of the initial negotiation being anything other than query/response - for example an EAP retry would be sourced from the acceptor and might not be expected by the initiator. 2. In section 1.2 para #2 - we have not established what the peer and authenticator are for EAP. It would be a good idea to identify who is whom. Suggest adding a sentence similar to the first sentence in the previous paragraph. 3. In section 1.2 - I have always been worried about the statement that EAP authentication can start w/ the peer, but the first message is always from the authenticator. I believe that it would be more correct to state that EAP authentication always starts with the authenticator, but it may start with the peer for any given EAP mechanism. 4. In section 1.2 - I would suggest that /GSS-API peer/ becomes /GSS-API acceptor/ This keeps the term peer to be used only for EAP and only for the GSS-API initiator (possibly unless we are dealing with terms for an EAP pass-through system) 5. In section 1.2 - You say that the GSS-API acceptor acts as an EAP pass-through authenticator. I am not sure if that means that the GSS-API acceptor needs to deal with the requirements for an EAP pass-through such as the fact that it is supposed to check the record value of EAP item rather than just pass-it through. 6. In section 3 - I have a real problem with the first sentence in the section. I don't believe that it is a true statement. What is authenticated is going to be based on what the EAP method is and what is expected. I have always assumed that it starts by authenticating a user to a realm as the single authentication and different things for mutual authentication. It might be that the sentence was supposed to be "EAP authenticates within a realm." 7. Is the BNF in section 3.1 supposed to ensure that a name cannot be "[email protected]"? Currently you would need to say "shartman/@janet.edu" 8. In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name would be useful for people w/o sufficient background. I would need to look farther on this, but based on this text I would end up with something like "smtp.example.com@SMTP" as a host name. However this looks very strange to me. 9. In section 3.3 -- Which acceptor name must be sent in the AAA transport? There are three different ones listed above, or this could be a completely different field. It might also be that the portions are to be re-composed in order to send onto the client in the EAP channel, if this is the case then why do the decomposition? 10. In section 3.3 - is the client signaling mutual authentication on the EAP channel or on the GSS-API channel? 11. In section 5.5 - who does the initiator return the error message to? What state should it transition to? Should it still accept an error from the acceptor in the GSS-API protocol? 12. In section 5.6 - It is not clear to me if one can progress from the Extension State to the Extension state rather than the completed state as part of negotiation of option features. Is this something that needs to be clarified? 13. In Section 5.6.1 - is the flag bit of 0x1 reserved for some purpose? If so this needs to be documented. If not then why not start with mutual auth at 0x1 rather than 0x2. 14. In section 5.6.3 - Do I assume that it is so obvious that it does not need to be stated that the EAP negotiated key is used for the MIC w/o any further key derivation work? 15. In section 5.7 - I am not clear what set of channel binding data needs to be included in the EAP method. Would this be data about the channel carrying the GSS-API methods or the GSS-API/AAA channel or both? I assume this should really include channel data all the way from the acceptor to the EAP server but I don't know that. How much does this differ from the acceptor name referenced in question 9? Typos: s/thearchitecture/the architectural/ or /the architectures/ s/authorisation/authorization/ - American English spellings preferred check if passthrough is a single word or should be pass-through. My dictionary dislikes it as a single word. s/receievs/receives/ s/faris/far is/ _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
