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 give 
the reader an accurate picture of all security considerations when doing 
EAP-POTP without an outer tunnel: I agree that it would be good to add a 
couple of illustrative examples on the actual strength one will get and 
will do so - I suggest to do this as an informative annex and then 
reference it from Section 6.1. I would however also like to point out that 
the calculations are only for the initial contact with a particular EAP 
server - 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 be 
secure from eavesdroppers/attackers.

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

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

Regarding the support for GTC, I think you're right. Work on this draft 
actually started almost three years ago ... and things have changed in 
this 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 text 
should state that for the default algorithms, the length shall be 16 
octets, but otherwise they shall be as defined by the negotiated crypto 
algorithms.

Finally, for the "tel" URI, you are right. Since the auth_id field is 
preceded by a length byte, it isn't a big problem to remove this 
restriction (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 arbitrary 
length. It does, however, feel a little bit of an overkill to allow 
arbitrary long tel URIs and thus expand the length octet to two for this 
reason alone. Do you feel that it would be important or that a note about 
this 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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf