Document: draft-torvinen-http-digest-aka-v2-01 Reviewer: Spencer Dawkins Date: July 17, 2004 This document is on the right track, especially for Informational (is this the right track for authentication mechanisms? but I defer to the ADs). Some nits exist (see attached mark-up), but I'm really only concerned about a couple of places where the document isn't clear to me - everything else could be fixed in authors 48-hour. ---------------------Markup----------------------- Abstract HTTP Digest is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exist not just with HTTP Digest S - "problem, not only with HTTP Digest..." but also with other IETF protocols that use tunneled authentication. This document defines version 2 of the HTTP Digest AKA algorithm. This algorithm can be implemented in a way that it is resistant to S- "that is resistant" the man-in-the-middle attack. 2. Introduction The Hypertext Transfer Protocol (HTTP) Digest Authentication, described in [RFC2617], has been extended in [RFC3310] to support Authentication and Key Agreement (AKA) mechanism [AKA-REF]. AKA mechanism performs authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. HTTP Digest AKA enables the usage of AKA as a one-time password generation mechanism for Digest authentication. HTTP Digest is known to be vulnerable to man-in-the-middle attacks, even when run inside TLS, if the same HTTP Digest authentication credentials are used in some other context without TLS. The attacker may initiate a TLS session with a server, and when the server challenges the attacker with HTTP Digest, the attacker masquerades the server to the victim. If the victim responds to the challenge, the attacker is able to use this response towards the server in HTTP S- "use this response towards the server" seems unclear - I'm not sure I understand the action the attacker uses or what the exposure for the victim is. Digest. Note that this attack is an instance of general attack that affects a number of IETF protocols such as PIC. The general problem is discussed in [Asokan-Niemi-Nyberg] and [Puthenkulam-binding-draft]. Because of the previous vulnerability, the use of HTTP Digest "AKAv1" should be limited to the situations where the client is able to demonstrate that in addition to the AKA response, it possess the AKA session keys. This is possible, for example, if the underlying security protocol uses the AKA generated session keys to protect the authentication response. This is the case for example in the 3GPP IP Multimedia Core Network Subsystem (IMS) where HTTP Digest "AKAv1" is currently applied. However, HTTP Digest "AKAv1" should not be used with tunnelled security protocols that do not utilize the AKA session keys. For example, the use of HTTP Digest "AKAv1" is not necessarily secure with TLS if the server side is authenticated using certificates and the client side is authenticated using HTTP Digest AKA. There are at least four potential solutions to the problem: 1. The use of the authentication credentials is limited to one application only. However, this would increase the total number of authentication credentials for an end-user, and would cause scalability problems in the server side. 2. The keys used in the underlying security protocols are somehow bind to the keys used in the tunneled authentication protocol. S- "bound" However, this would cause problems with the current implementations of underlying security protocols. For example, it is not possible to use the session keys from TLS at application S- either a citation or a few words of explanation about why this is not possible would be nice here. layer. Furthermore, this solution would only solve the problem when HTTP Digest is used over one hop, and leave the problem of using HTTP Digest via multiple hops, e.g. via proxy servers, unsolved. 3. Authentication credentials are used in cryptographically different way for each media and/or access network. However, it S- I'm not sure what this means. may be difficult to know which underlying media is used below the S- "below each application" application. 4. Authentication credentials are used in cryptographically different way for each application. This document specifies a new algorithm version for HTTP Digest AKA, i.e. "AKAv2". "AKAv2" specifies a cryptographically different way to use AKA credentials in use cases that are based either on HTTP Digest authentication or UMTS authentication (cf. approach 4 above). The only difference to "AKAv1" is that in addition to AKA response RES the AKA related session keys, IK and CK, are also used as the S- This document has an excellent terminology section, but it would still be nice to expand terms like "IK" when they are introduced in the text. password for HTTP Digest. AKAv2 is immune to man-in-the-middle attack described above. However, if AKAv2 is used in some environment both with and without some underlying security, such as TLS, the problem still exists. New HTTP Digest AKA algorithm versions can be registered in IANA based on Expert Review. Documentation of new algorithm versions is not mandated as RFCs. However, "AKAv2" is documented as an RFC because the use of different AKA algorithm versions includes security implications that the implementators should be aware of. The extension version and security implications are presented in this document. 5. Security Considerations 5.1 Multiple Authentication Schemes and Algorithms The rules for an user agent for choosing among multiple authentication schemes and algorithms are as defined in [RFC3310] except that the user agent MUST choose "AKAv2" if both "AKAv1" and "AKAv2" are present. Since HTTP Digest is known to be vulnerable for bidding-down attack in environments where multiple authentication schemes and/or algorithms are used, the system implementators should pay special attention for scenarios where both "AKAv1" and "AKAv2" are used. S- It would be nice to make a more specific recommendation here. Especially if the AKA generated sessions keys or some other additional security measures to authenticate the clients, such as client certificates, are not used, the use of both AKA algorithm versions should be avoided. S- this sentence is just a little too inverted. "The use of both AKA algorithm versions should be avoided especially if the AKA generated session keys (or some other mechanism) is not used to authenticate the clients" - and I'm still not sure how client certificates figure into this.