Proposed Resolution to Issue 78:

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

1.3 Overview
[..]
   RADIUS clients and servers can support one, or both nonce generation
   modes.

   If the RADIUS server generates nonces, its RADIUS clients MUST NOT
   try to generate nonces.  If the RADIUS server does not generate
   nonces, its RADIUS clients MUST generate nonces locally.  If at least
   one HTTP-style client requires AKA authentication [RFC3310], the
   RADIUS server MUST generate nonces and its RADIUS clients MUST NOT
   generate nonces locally.  The nonce generation mode is a configurable
   parameter

   The operator MUST make sure that the RADIUS client software uses the
   correct nonce generation mode when accessing a specific RADIUS
   server.  RADIUS clients implementing both modes MUST offer respective
   configuration options.

[For new formatting, see to draft-ietf-radext-digest-auth-02.txt]

3.1  Digest-Response attribute

   Description
         If this attribute is present in an Access-Request message, the
         RADIUS server MUST view the Access-Request as a Digest one.
[..]

   Length
         >= 3
   Text
         When using HTTP digest, the text field is 32 octets long and
         contains hexadecimal representation of 16 octet digest value as
         it was calculated by the authenticated client.  Other digest
         algorithms MAY define different digest lengths.  The text field
         MUST be copied from request-digest of digest-response
         ([RFC2617]) without quotes.

[..]
3.10  Digest-Entity-Body-Hash attribute

   Description
         When using the qop level 'auth-int', a hash of the HTTP-style
         message body's contents is required for digest calculation.
         Instead of sending the complete body of the message, only its
         hash value is sent.  This hash value can be used directly in
         the digest calculation.

         The clarifications described in section 22.4 of [RFC2617] about
         the hash of empty entity bodies apply to the Digest-Entity-
         Body-Hash attribute.  This attribute MUST only be sent in
         Access-Request packets.
   Type
         [IANA: use 111 if possible] for Digest-Entity-Body-Hash
   Length
         >=3
   Text
         The attribute holds the hexadecimal representation of H(entity-
         body).  This hash is required by certain authentication
         mechanisms, such as HTTP Digest with quality of protection set
         to "auth-int".  RADIUS clients MUST use this attribute to
         transport the hash of the entity body when HTTP Digest is the
         authentication mechanism and the RADIUS server requires to
         verify the integrity of the entity body (e.g., qop parameter
         set to "auth-int").  Extensions to this document may define
         support for authentication mechanisms other than HTTP Digest.

wb: extension would be indicated by Digest-Algorithm or Digest-Qop, of
course.

Migration Path to Diameter:

still left in -02, as there is no diameter-sip-app draft describing the
functionality yet.


Wolfgang Beck
--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
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/>