Skip to main content

Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2
draft-torvinen-http-digest-aka-v2-02

Revision differences

Document history

Date Rev. By Action
2012-08-22
02 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2005-07-04
(System) Posted related IPR disclosure: Nokia Corporation's statement about IPR claimed in draft-torvinen-http-digest-aka-v2-02.txt
2005-03-16
02 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-03-14
02 Amy Vezza IESG state changed to Approved-announcement sent
2005-03-14
02 Amy Vezza IESG has approved the document
2005-03-14
02 Amy Vezza Closed "Approve" ballot
2005-03-10
02 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2005-01-26
02 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-11-24
02 Allison Mankin Ready for re-review by Ted on return Dec 5
2004-11-24
02 Allison Mankin Note field has been cleared by Allison Mankin
2004-11-15
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-11-15
02 (System) New version available: draft-torvinen-http-digest-aka-v2-02.txt
2004-07-23
02 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-07-23
02 Amy Vezza [Note]: 'Blue Team
Reviewed by Ekr.  Wanted more clarity but did not see security hole.  Looking for any other concerns.' added by Amy Vezza
2004-07-23
02 (System) Removed from agenda for telechat - 2004-07-22
2004-07-22
02 Thomas Narten
[Ballot comment]
> 6. IANA Considerations
>
>    This document specifies a new aka-version, "AKAv2", to the
>    aka-version namespace maintained by IANA. …
[Ballot comment]
> 6. IANA Considerations
>
>    This document specifies a new aka-version, "AKAv2", to the
>    aka-version namespace maintained by IANA. The allocation of new
>    aka-versions is up to Expert Review as outlined in [RFC2434].

Better:

  This document specifies a new aka-version, "AKAv2", to the
  aka-version namespace maintained by IANA. The procedure for
  allocation of new aka-versions is defined in [RFC3310].

I.e., document should reference the text that defines the policy, not
just state what the policy is.
2004-07-22
02 Thomas Narten [Ballot Position Update] New position, Undefined, has been recorded for Thomas Narten by Thomas Narten
2004-07-22
02 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2004-07-22
02 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-07-21
02 Ted Hardie
[Ballot discuss]
In the Security considerations section, the draft says:

  1.  The victim contacts the attacker using TLS. If the attacker has a
  …
[Ballot discuss]
In the Security considerations section, the draft says:

  1.  The victim contacts the attacker using TLS. If the attacker has a
      valid server certificate, the client may continue talking to the
      attacker and use some HTTP authentication compatible protocol,
      such as Session Initiation Protocol (SIP).

  2.  The attacker contacts some real proxy/server also using TLS and
      some HTTP authentication compatible protocol. The proxy/server
      responds to the attacker with HTTP Authentication challenge.

  3.  The attacker forwards the HTTP Authentication challenge from the
      proxy/server to the victim. If the victim is not careful, and
      check that the identity in the server certificate in TLS matches
      the realm in the HTTP authentication challenge, it may send a new
      request which carries a valid response to the HTTP Authentication
      challenge.

I think the example isn't clear whether the HTTP auth-compatible protocols in 1 & 2
are/must be/might not be  the same protocol  Using an example based on SIP also
seems a bit strange given this text:

  If the session keys are used with some other applications than HTTP
  authentication, they MUST use some other application specific string
  than "http-digest-akav2-integritykey" or
  "http-digest-akav2-cipherkey" to mask the original session keys.

I took that to mean SIP would use "http-digest-akav2-sip-integritykey" and
so on; if it would not, then I the text above needs some clarification that
"other applications than HTTP authentication" doesn't mean HTTP, it means
*any application using HTTP's authentication mechanisms".

To clear this discuss, I would appreciate the authors to make clear in
the text in which cases the string "http-digest-akav2-integritykey" (or its partner)
is reused and in which it is not.  I think there is an interoperability risk
at this point, as some folks implementing it for things like SIP might pick
a new string and others might re-use.  Supporting that text with the example
cited would be needed as well.
2004-07-21
02 Russ Housley
[Ballot comment]
Please add the RFC number of the AKAv1 to the Abstract.  I suggest:

    The HTTP Digest as specified in RFC 3310 …
[Ballot comment]
Please add the RFC number of the AKAv1 to the Abstract.  I suggest:

    The HTTP Digest as specified in RFC 3310 is known to be ...
2004-07-21
02 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-07-20
02 Ted Hardie
[Ballot discuss]
In the Security considerations section, the draft says:

  1.  The victim contacts the attacker using TLS. If the attacker has a
  …
[Ballot discuss]
In the Security considerations section, the draft says:

  1.  The victim contacts the attacker using TLS. If the attacker has a
      valid server certificate, the client may continue talking to the
      attacker and use some HTTP authentication compatible protocol,
      such as Session Initiation Protocol (SIP).

  2.  The attacker contacts some real proxy/server also using TLS and
      some HTTP authentication compatible protocol. The proxy/server
      responds to the attacker with HTTP Authentication challenge.

  3.  The attacker forwards the HTTP Authentication challenge from the
      proxy/server to the victim. If the victim is not careful, and
      check that the identity in the server certificate in TLS matches
      the realm in the HTTP authentication challenge, it may send a new
      request which carries a valid response to the HTTP Authentication
      challenge.

I think the example needs a bit of wordsmithing.  It isn't clear whether
the HTTP auth-compatible protocols in 1 & 2 are/must be/might not be
the same protocol  Using an example based on SIP also seems a bit strange given
this text:

  If the session keys are used with some other applications than HTTP
  authentication, they MUST use some other application specific string
  than "http-digest-akav2-integritykey" or
  "http-digest-akav2-cipherkey" to mask the original session keys.

I took that to mean SIP would use "http-digest-akav2-sip-integritykey" and
so on; if it would not, then I the text above needs some clarification that
"other applications than HTTP authentication" doesn't mean HTTP, it means
*any application using HTTP's authentication mechanisms"
2004-07-20
02 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to Discuss from Undefined by Ted Hardie
2004-07-20
02 Ted Hardie
[Ballot comment]
In Section 2, the draft says:

      The use of the authentication credentials is limited to one
      application …
[Ballot comment]
In Section 2, the draft says:

      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.

First, I believe we already tell folks that limiting the use of authentication
credentials to a single use is a darn good idea.  Second, I believe
the authors are thinking of a particular type of server (multi-function
servers, i'd guess) when they are thinking of the scaling problem, and more
detail there would be useful.

  2.  The keys used in the underlying security protocols are somehow
      bind to the keys used in the tunneled authentication protocol.
      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

bind-->bound.

      Authentication credentials are used in cryptographically
      different way for each media and/or access network. However, it
      may be difficult to know which underlying media is used below the
      application.

media-->medium
2004-07-20
02 Ted Hardie
[Ballot comment]
In Section 2, the draft says:

      The use of the authentication credentials is limited to one
      application …
[Ballot comment]
In Section 2, the draft says:

      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.

First, I believe we already tell folks that limiting the use of authentication
credentials to a single use is a darn good idea.  Second, I believe
the authors are thinking of a particular type of server (multi-function
servers, i'd guess) when they are thinking of the scaling problem, and more
detail there would be useful.

  2.  The keys used in the underlying security protocols are somehow
      bind to the keys used in the tunneled authentication protocol.
      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

bind-->bound.
2004-07-20
02 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-07-20
02 Scott Hollenbeck [Ballot comment]
I see one non-ASCII-looking character (䳬) in the name of one of the authors.
2004-07-20
02 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-07-20
02 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2004-07-20
02 Allison Mankin Ballot has been issued by Allison Mankin
2004-07-20
02 Allison Mankin Created "Approve" ballot
2004-07-20
02 (System) Ballot writeup text was added
2004-07-20
02 (System) Last call text was added
2004-07-20
02 (System) Ballot approval text was added
2004-07-15
02 Allison Mankin [Note]: 'Blue Team
Reviewed by Ekr.  Wanted more clarity but did not see security hole.  Looking for
any other concerns.' added by Allison Mankin
2004-07-15
02 Allison Mankin Placed on agenda for telechat - 2004-07-22 by Allison Mankin
2004-07-15
02 Allison Mankin State Changes to IESG Evaluation from AD Evaluation by Allison Mankin
2004-03-24
02 Allison Mankin Draft Added by Allison Mankin
2003-09-02
01 (System) New version available: draft-torvinen-http-digest-aka-v2-01.txt
2003-06-16
00 (System) New version available: draft-torvinen-http-digest-aka-v2-00.txt