Subject: [abfab] AD review of draft-ietf-abfab-gss-eap-07

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jun 2012 18:54:51 +0100

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.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 20 Jun 2012 20:57:56 +0200

On 06/20/2012 07:54 PM, Stephen Farrell wrote:
> 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.
> 

Depends on Sams answers to the questions.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Jun 2012 15:15:21 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> 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-masked]
    Stephen> https://www.ietf.org/mailman/listinfo/abfab

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jun 2012 22:46:38 +0100

Hi Sam,

Just to note that this all looks good to me and
proceeding as you indicate seems like a fine plan.

Thanks,
S

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 20 Jun 2012 15:32:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, June 20, 2012 12:15 PM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: Re: [abfab] AD review of draft-ietf-abfab-gss-eap-07
> 

This matches what I would have expected.

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

> 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.
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.
output
> length is also 128.
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.
> 
other
> than the IETF  would use that registry rather than just grabbing their own
> OID.
> think of a reason for allocation other than to an IETF stream document and
> other allocations are expected to be declined.
would you
> want to?

7.1 NIT - just noticed that the description of GSS_EAP_NT_EAP_NAME is not in
the table

> I'd also be totally fine with expert review with a note that experts are
very
> likely to insist on IETF stream documents.
> 
> 
> The general public-key timing attacks against say TLS don't seem to apply.
specific
> to this mechanism or cases where EAP has already failed and generated its
> own failure.
> Because the NAI spec is kind of broken and confuses encoding with format.
> However, the AAA community was really unhappy when they thought we
> were going to actually use the NAI spec.

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.

> 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 the back reference to 3.4 correct in the last para

But only if the text is not deleted per current instructions.

Jim

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Jun 2012 19:02:17 -0400

OK, so based on Jim's comments we definitely need to refine what we
propose to delete from 3.4.

I'd also appreciate input on registration procedures for 7.1 and 7.7;
details of the discussion in my original response to Stephen.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Jun 2012 11:10:25 -0400

I am uploading 08 as I write. I think this is ready for last call.
I believe I've addressed most of your nits and all of your questions.

Some nits I leave to the rfc editor. They're better at fixing up
references than I'll ever be.
Also, while I appreciate your desire to have a title on the figure on
page 16, there's already one there. It's just that xml2rfc in its
infinite wizdom believes that the title of a texttable goes *at the
bottom*. Who am I to question such an august source about the proper
formatting of documents?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 Jun 2012 16:15:46 +0100

Ack, will start IETF LC when I see -08 (later this pm)

S