>>>>> "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
