Thanks Jim! Klaas
On Oct 4, 2011, at 10:34 PM, Jim Schaad wrote: > 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
