Status of draft-sterman issues

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Hello,

below, I've compiled the open issues and solution proposals of draft-sterman.
Issue 8 (Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int) made quite a few changes necessary. Do we need a second WG Last
Call ?

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

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt 



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>