Last call comments for draft-nystrom-eap-potp-05

[<[e-mail]>]

I have two substantive comments, and a couple of more minor comments:

1) I am concerned that the document does not give the reader an
accurate picture of the security considerations involved when all
EAP-POTP exchanges are done without a server-authenticated tunnel
(such as PEAP).

The problem is that OTPs are typically quite short, and thus a
brute-force attack can be feasible, depending on various parameter
values. Due to quite complex interaction of salt, pepper, OTP and PIN
it's not easy to figure out exactly how the parameter values influence
the difficulty of brute-force attacks, and the security claims in
Section 6.1 simply say that:

   Key strength:              Depends on size of OTP value, strength of
                              underlying shared secret, strength and
                              characteristics of OTP algorithm, pepper
                              length, iteration count, and whether the
                              method is used within a tunnel such as
                              PEAP.

Let's calculate one data point. Assume an RSA SecurID token with PIN
input on the token and 6-digit output (this is what I've used at more
than one employer). For the iteration count, let's follow Section
4.10.3: "The "iteration_count" value MUST be chosen to provide a
suitable level of protection (e.g. at least 2000)".

The document does not recommend any particular value for the pepper
length, except that "When pepper is used, it is RECOMMENDED that the
length of the pepper and the iteration count are chosen in such a way
that it is computationally infeasible/ unattractive for an attacker to
brute-force search for the given OTP within lifetime of that OTP."
(That was helpful.)

However, increasing the (client-selected) pepper length by 10 bits
increases the server's work by roughly 1000x.  Typical RADIUS servers
support thousands of authentications per second, so it's not realistic
to assume very long client-selected peppers.  (And even if server
capacity was not a concern, users would get annoyed if the
authentication process took more than a couple of seconds.) Thus,
let's assume pepper length of 10 bits.

Given these paremeters, it looks like the effective key strength would
be roughly 41 bits (log2(10^6)+log2(2000)+10) (+- some small constant
to scale to the "effort comparable to [..] operations of a typical block
cipher" scale used in RFC3748).  In other words: a completely feasible
brute-force search that gives the attacker the MSK (could be used to
decrypt captured WLAN traffic) and the SRK (could be used for session
resumption).

Even though the session lifetime could be quite short (but there's no
guidance on how short would be secure enough!), the contents of the
WLAN traffic (encrypted using keys derived from the MSK) could be
valuable for a long time (several years).

While some of these parameters could be larger (say, 8-digit output
from token, PIN and iteration count/pepper length leading to 10x more
effort), it seems that parameter values large enough to get 128 bit of
key strength (as required by RFC 4017) are simply not feasible: while
an attacker can spend 2^40 effort on a brute force attack, the real
server cannot do that much for each valid authentication.

In other words: I believe the document should at least clearly say
that when used without a server-authenticated tunnel, and with typical
values for client-selected pepper length and iteration count, EAP-POTP
is vulnerable to brute-force attacks, and does not provide sufficient
key strength to meet the requirements of [RFC4017].

Furthermore, given that in EAP-POTP the key strength depends heavily
on user/administrator selected parameters, the document should follow
RFC 3748's advice about key strength: "The statement SHOULD be
accompanied by a short rationale, explaining how this number was
derived.  This explanation SHOULD include the parameters required to
achieve the stated key strength based on current knowledge of the
algorithms."

Similarly, statements such as "If the server did not indicate support
for pepper searching, then the PBKDF2 computation MUST be carried out
with a sufficiently higher number of iterations so as to compensate
for the lack of pepper." do not allow the average reader to determine
how high number would be sufficient (and it looks like that without a
server-authenticated tunnel, high enough numbers can't be used in
practice).

2) The document suggests that some EAP-POTP exchanges can be done
inside a server-authenticated tunnel while others could be outside of
it (e.g., Section 6.4 "initial exchanges with EAP servers SHOULD occur
in a secure environment (e.g. in a PEAP tunnel)"). This would be
extremely unwise if the tunnel method does not support cryptographic
binding (e.g., EAP-TTLSv0, PEAPv0, or PEAPv1), as it leads to an easy
man-in-the-middle attack.

Couple of minor comments:

3) The document would be much easier to understand if it said in the
introduction that the "basic" variant can be used only inside a
server-authenticated tunnel, while the "protected mode" can be used
both with and without such tunnel. Currently, the reader finds this
information only after 58 pages!

4) Section 1.3: "However, investigations (e.g. [12]) have shown that
EAP implementations in general do not support GTC."

That might have been the situation five years ago (when [12] was
written), but I'd say that today most EAP implementations do support
GTC, usually together with PEAP. Everyone in the "Cisco Compatible
Extensions" program does (a long list of familiar vendor names). The
Intel WLAN software I'm using does. Some Nokia phones with WLAN do.
RADIUS servers from Interlink, Juniper/Funk and Cisco do. (At least
based on a quick web browsing session.)

5) Section 4.5 says that "K_MAC, K_ENC, and SRK SHALL be 16 octets";
doesn't this limit algorithm agility? And the spec already contains
3DES which doesn't use 128-bit keys?

6) Section 4.10.3 assumes that tel URIs are at most 32 octets in
length, but RFC2806 does not have this limitation, and even says that
"implementations MUST NOT assume that telephone numbers have a
maximum, minimum or fixed length".


Best regards,
Pasi

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf