Hi Sam, Just to note that this all looks good to me and proceeding as you indicate seems like a fine plan.
Thanks, S On 06/20/2012 08:15 PM, Sam Hartman wrote: >>>>>> "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. > > 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.) > > 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.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? > > > 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. > > 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. > > > 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
