Hi, Pretty well written document, thanks.
I've some questions and a bunch of nits below. I reckon this'll be ok to go to IETF LC, but want to check to see if you'd prefer to shoot out a revised I-D first. If you'd rather do IETF LC with -07, that's fine and you can respond to my questions along with IETF LC comments. I'll wait for a chair to tell me what you prefer. Cheers, S. Questions: (1) 3.4: the abnf in 3.1 has service-specifics which can have 0 or more service-specific values but the AVP here is called "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 service-specific value is part of a name does that mean all of those are put in one AVP (with what separator?) or that multiple AVPs are sent? (I can't recall the RADIUS rules on AVPs right now). (2) Section 6: where are the pseudo-random and truncate functions defined? pseudo-random is presumably from 3961 but exactly which one? (Ah - If its from 4402 as 6.3 says, then please move that one line up to where CRK is defined.) I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", if "||" is catenation and truncate(L,x) returned the left-most L bits of x, then adding more Tn's (on the right) will not have any effect after a while. I'm also not clear about the limits for "n" - are you just meant to iterate "n" until there are more than L bits to input to truncate()? If so, then I think you need to say that. (I reckon I figured it out in the end, but have left the comment as was to show how I got confused;-) (3) 6.2 uses the CRK as both sub-session key and ticket session key. Is that ok? Not asking you put the explanation in the draft, just checking that the WG/authors thought about it. (I don't recall 4121 well enough to be sure without reading it all again.) (4) 7.1 & 7.7 - do you really need IETF review for these? Wouldn't expert review be ok? Just checking. (5) Should there be any warnings about potential timing attacks against implementations of this? There are a lot of error conditions that say you MUST send an error so the timing of that might give something away. Having said that I don't see a case where a secret might leak, though with all the potential EAP methods it'd be hard to know for sure, but I wonder if the WG have thought about that. (If text needs adding it'd be fine to add after IETF LC as well but this isn't quite a nit.) nits ---- - ID-nits has some issues with the references (some are RFCs, some updated), and has (possibly spurious) issues with some example FQDNs and IP addresses. - expand NAS on 1st use - 1.2, does GSS-API "provide" guaranteed delivery? That's confusing, since GSS-API tokens are carried by the application protocol. Maybe s/provides/assumes/? - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 doesn't make it clear. (Maybe its later?) - section 3, a forward reference to where the policy DB is described might be useful in the 2nd last para before 3.1 - 3.1, "similar to the portion of a [NAI] before the @ symbol" sounds quite vague - why say it that way? (I've seen the phrase "similar" generate discusses before.) - 3.1 (or section 3, generally) could *really* do with some examples and the text is very complicated - if you could find someone to do a pass to try simplify that'd be great. - The text for the RFC editor to delete in 3.4 might be better as part of the iana considerations section - more common to see it there (you can put a ptr in 3.4 and a back-ptr in 7.x saying "don't forget to delete the ptr in 3.4" maybe) - As an alternative to removing the VSA text in 3.4, would that be useful as an appendix in the RFC that says "here's what we used to do before we had an official assignment...you might still see that in the wild" ? - section 4 start: s/The specification/This specification/? (twice in that para maybe) - section 4, 4th para: are the "should"'s here meant to be 2119 language? Seems like not, in which case maybe s/should/can/ (twice)? - section 4 ends on the bad news, might be good to say at the end why that's ok really - p16, be good to give the figure a name, and say that the position column is byte position - section 5: might be nice to say that 06 01 and 06 02 are hex and give the decimal equivalents just in case. - 5.1, this is the first mention of "mechanism family" might be good to introduce that idea earlier? - 5.4.3, typo s/be send/be sent/ - 5.5, the tools page rendering of the reference to "Section 7.10 [RFC3748]" is odd - I think if you said "Section 7.10 of [RFC3748]" it'd look better and generate the right link. - 5.5, typo: s/receivs/receives/ - 5.6.2, CRK could be expanded on 1st use - 5.8, is there a clear list of EAP methods that provide dictionary attack resistance? Could you provide a reference? At least the most commonly expected method would be good to mention. - 5.8 - is the back reference to 3.4 correct in the last para here? - section 6, typo: s/procedur/procedure/ - 6.1, typo: s/providing by/provided by/ - 6.1, what is "HTTP Negotiate" - maybe add an informative reference? - 7.1, You'll get asked (by Barry:-) to specify the precise name of the registry for IANA. - 7.2, 1st para has some text you don't want in the RFC, and some you do - better to indicate what's what. (Same for 7.4) - 7.6, the "implementations MUST be prepared to receive them" is a bit hidden here, was it also stated earlier? Might be a good plan. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
