: drafts-sterman-aaa-sip-04 is available

An updated draft of draft-sterman-aaa-sip is available:
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Changes:

Issue 3:
1) Abstract
new text:
'Several protocols borrow the syntax and authentication mechanisms
from the Hypertext Transfer Protocol, HTTP.  This document specifies
an extension to RADIUS that allows a RADIUS client in a HTTP-style
server, upon reception of a request, retrieve and compute Digest
authentication information from a RADIUS server.  Additionally, a
scenario describing  the authentication of a user emitting a
HTTP-style request is provided.'

2) body digest
renamed to Digest-Entity-Body-Hash

3) figures in attribute description
only one figure for all attributes

4) mentioning of early number assignments
removed

5) DIAMETER
-> Diameter

6) IANA request
added "This document serves as IANA registration request for ..."

7) horrible examples
shortened and fixed

Issue 4:
1) Attribute reuse
removed attribute reuse, introduced new attributes

Issue 5:
1) Digest-Stale
Use is now mandatory if server chooses nonces. 

2) Typos

Issue 6:
1) Overview too short
added overview section, rearranged document structure
     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  6
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  7

2) missing explanation for pre-computed hashes
new text:
'However, when using AKA [RFC3310] the nonce is partially derived from
a precomputed authentication vector.  These authentication vectors are
often stored centrally.'

3) unclear defintion of 'secured connection' 
added a reference to Security Considerations,
added explanation in Security Considerations

Issue 7:
Use of Message Authenticator should be mandatory
RfC 2869 is informational. I see that it is useful but
I hesitate to make it mandatory. 
new text:
'Informational RfC 3579 [RFC3579], section 3.2 describes
a Message-Authenticator attribute which MAY be used to protect the
integrity of RADIUS messages.'

Issue 8:
Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int 

In contrast to Diameter, RADIUS has no mandatory encryption support.
Sending H(A1) in the clear can make some attacks easier. Here's
the compromise:

A new attribute Digest-HA1 is introduced. It's use is restricted
to *-sess algorithms, where HA1 is constructed partially from random
values. 
From the text:

   o  If the Digest-QoP attribute's value is 'auth' or unspecified, the
      RADIUS server puts a Digest-Response-Auth attribute into the
      Access-Accept message
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5-sess' or
      'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute
      into the Access-Accept message.
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the
      RADIUS server MUST NOT send a Digest-HA1 attribute unless the
      connection between RADIUS server and client is encrypted or
      otherwise protected against eavesdropping.

Issue 9:
On suggestion of Avi Lior, I replaced the special Access-Accept
with Access-Challenge

(Issue 10 refers to NAIbis)

Issue 11:
1) missing reference
new text:
'Due to the limitations and weaknesses of Digest authentication (see
   [RFC2617], section 4 />)..'

2) when to use server generated nonces
added a paragraph in the overview section



Wolfgang