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

Pasi,

Thanks very much for your review.

On the first issue, that you are concerned that the document does not givethe reader an accurate picture of all security considerations when doingEAP-POTP without an outer tunnel: I agree that it would be good to add acouple of illustrative examples on the actual strength one will get andwill do so - I suggest to do this as an informative annex and thenreference it from Section 6.1. I would however also like to point out thatthe calculations are only for the initial contact with a particular EAPserver - similar to how things are done e.g. in Bluetooth, as long as the"pairing" happens (i.e. a long, server-provided pepper established)without an eavesdropper or active attacker, future handshakes will besecure from eavesdroppers/attackers.

The second issue, yes, I will clarify by stating "...that provides acryptographic binding with inner EAP methods" and make sure this is clearwhenever references to tunneling are made. I will remove the reference toTTLSv0.

Concerning your third issue, I will add a statement to section 1.2explaining that basic mode is only to be used within a tunnel, and thenrefer the reader to Section 6.

Regarding the support for GTC, I think you're right. Work on this draftactually started almost three years ago ... and things have changed inthis time frame. I will reformulate this section to reflect this.

For K_MAC, K_ENC, and SRK, that seems as a very good catch! The textshould state that for the default algorithms, the length shall be 16octets, but otherwise they shall be as defined by the negotiated cryptoalgorithms.

Finally, for the "tel" URI, you are right. Since the auth_id field ispreceded by a length byte, it isn't a big problem to remove thisrestriction (noting of course, that we still want to avoid fragmentation).This allows tel URIs to be up to 255 bytes long, so still not of arbitrarylength. It does, however, feel a little bit of an overkill to allowarbitrary long tel URIs and thus expand the length octet to two for thisreason alone. Do you feel that it would be important or that a note aboutthis would be sufficient?


-- Magnus

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(106)+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 240 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf