> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sam Hartman > Sent: Wednesday, June 20, 2012 12:15 PM > To: Stephen Farrell > Cc: [email protected] > Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07 > > >>>>> "Stephen" == Stephen Farrell <[email protected]> writes: > > > Stephen> (1) 3.4: the abnf in 3.1 has service-specifics which can have > Stephen> 0 or more service-specific values but the AVP here is called > Stephen> "GSS-Acceptor-Service-specific" (i.e. its singular). If >1 > Stephen> service-specific value is part of a name does that mean all of > Stephen> those are put in one AVP (with what separator?) or that > Stephen> multiple AVPs are sent? (I can't recall the RADIUS rules on > Stephen> AVPs right now). > > Good catch. > my preference is to send one AVP with / separator. > I.E. send the text string that is input. > However this has not been discussed.
This matches what I would have expected. > > Stephen> (2) Section 6: where are the pseudo-random and truncate > Stephen> functions defined? pseudo-random is presumably from 3961 but > Stephen> exactly which one? ( > > > The one for the enctype of the mechanism in question. > I.E. if this is eap-aes128, then the GMSK is an aes-128-cts-hmac-sha1-96 key > so you use the aes128-cts-hmac-sha1-96 pseudo-random function. > > Stephen> Ah - If its from 4402 as 6.3 says, then > Stephen> please move that one line up to where CRK is defined.) > > Sounds like we need to specify what pseudo-random and make it clear that > this in an internal call to pseudo-random, not the pseudo-random > construction from 4402 that is exposed to users. > (The construction from 4402 is actually the same with a different constant > fed into the PRF so that an application can never get the same pseudo- > random output as used for internal key derivation.) Yes, I would have probably messed that one up. > > Stephen> I'm also confused about "truncate(L, T0 || T1 || .. || Tn)", > Stephen> if "||" is catenation and truncate(L,x) returned the left-most > Stephen> L bits of x, then adding more Tn's (on the right) will not have > Stephen> any effect after a while. > > Exactly. > This construction deals with the fact that a Kerberos PRF may output less bits > than you need. So, you'd kind of expect that only the bits that you need > count towards the key. > The truncation and expansion is not intended to add cryptographic strength; > either your PRF is good or you're out of luck. It's simply intended to deal with > a potential mismatch between PRF output length and key bits. > For aes128, l=128 and only t0 counts towards the key because the prf output > length is also 128. > So in aes128's case this devolves to a simple call to the prf. > > Stephen> I'm also not clear about the limits > Stephen> for "n" - are you just meant to iterate "n" until there are > Stephen> more than L bits to input to truncate()? If so, then I think > Stephen> you need to say that. (I reckon I figured it out in the end, > Stephen> but have left the comment as was to show how I got confused;-) > > Right. > An explanatory paragraph is needed here. > > Stephen> (3) 6.2 uses the CRK as both sub-session key and ticket > Stephen> session key. Is that ok? Not asking you put the explanation in > Stephen> the draft, just checking that the WG/authors thought about it. > Stephen> (I don't recall 4121 well enough to be sure without reading it > Stephen> all again.) > > I wrote that text to make sure the context would be well formed in terms of > how implementations tend to represent the context and use it for some AD- > specific applications. > In practice I don't think anything standards-track will use the ticket key if the > sub-session key is present. > > I'm fairly sure this is OK, but I'd appreciate a sanity check from Nico or luke or > someone else who has looked at 4121 a lot. > > Stephen> (4) 7.1 & 7.7 - do you really need IETF review for these? > Stephen> Wouldn't expert review be ok? Just checking. > > 7.1: I argue IETF review is appropriate because I can't see why anyone other > than the IETF would use that registry rather than just grabbing their own > OID. > I'd support making it expert review with a note that we cannot currently > think of a reason for allocation other than to an IETF stream document and > other allocations are expected to be declined. > I.E. there's no harm in using that registry for other things, but why would you > want to? 7.1 NIT - just noticed that the description of GSS_EAP_NT_EAP_NAME is not in the table > > 7.7: There are only 32 possible values to be allocated. > I'd also be totally fine with expert review with a note that experts are very > likely to insist on IETF stream documents. > > > Stephen> (5) Should there be any warnings about potential timing > Stephen> attacks against implementations of this? There are a lot of > Stephen> error conditions that say you MUST send an error so the > Stephen> timing of that might give something away. Having said that I > Stephen> don't see a case where a secret might leak, though with all > Stephen> the potential EAP methods it'd be hard to know for sure, but I > Stephen> wonder if the WG have thought about that. (If text needs > Stephen> adding it'd be fine to add after IETF LC as well but this > Stephen> isn't quite a nit.) > > > I know I have not thought about this at all. > The general public-key timing attacks against say TLS don't seem to apply. > For one thing we don't actually create any new requirements for the EAP > server. > So, failure cases where we require an error to be sent are generally specific > to this mechanism or cases where EAP has already failed and generated its > own failure. > However, review could help here. > > Stephen> ---- > > Stephen> - Is GSS_Pseudo_random MTI? Its a normative reference but 1.3 > Stephen> doesn't make it clear. (Maybe its later?) > > > I consider it MTI. > > Stephen> - 3.1, "similar to the portion of a [NAI] before the @ symbol" > Stephen> sounds quite vague - why say it that way? (I've seen the > Stephen> phrase "similar" generate discusses before.) > > Because the NAI spec is kind of broken and confuses encoding with format. > It's being revised but we don't want to block on that. > However, the AAA community was really unhappy when they thought we > were going to actually use the NAI spec. > Stephen> - As an alternative to removing the VSA text in 3.4, would > Stephen> that be useful as an appendix in the RFC that says "here's > Stephen> what we used to do before we had an official assignment...you > Stephen> might still see that in the wild" ? > > I like this. > Thoughts? It is not clear to me that all of section 3.4 should be deleted by the RFC editor. Specifically looking at the text starting with "If RADIUS is used as an AAA transport". This text is not reproduced in the registration code below. > > > Stephen> - section 4, 4th para: are the "should"'s here meant to be > Stephen> 2119 language? Seems like not, in which case maybe > Stephen> s/should/can/ (twice)? > Definitely not as it's a description of an alternative not taken. > > can seems wrong there to me. I have been fighting this battle by changing the 2119 slightly to be "When the keys words ... are in upper case ...". I saw this in another standards group and it deals with the casing question. > > Stephen> - 5.8, is there a clear list of EAP methods that provide > Stephen> dictionary attack resistance? Could you provide a reference? > Stephen> At least the most commonly expected method would be good to > Stephen> mention. > > I don't know what the commonly expected method is. > In general people get this by running over a tunnel. > > Stephen> - 5.8 - is the back reference to 3.4 correct in the last para > Stephen> here? > > It is. But only if the text is not deleted per current instructions. Jim > > > Yes, I believe so. > > Stephen> _______________________________________________ > Stephen> abfab mailing list > Stephen> [email protected] > Stephen> https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
