Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2
RFC 4169

Note: This ballot was opened for revision 02 and is now closed.

(Allison Mankin) Yes

(Margaret Cullen) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2004-07-20)
No email
send info
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

(Scott Hollenbeck) No Objection

Comment (2004-07-20 for -)
No email
send info
I see one non-ASCII-looking character (䳬) in the name of one of the authors.

(Russ Housley) No Objection

Comment (2004-07-21 for -)
No email
send info
  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 ...

(Bert Wijnen) No Objection

(Thomas Narten) No Record

Comment (2004-07-22 for -)
No email
send info
> 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.