AW: [secdir] draft-ietf-radext-digest-auth06.txt, proposal

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

I think we have two options
1. remove the mode where the RADIUS client generates nonces
2. embed a time-stamp into the nonce

Option 1. would be easy but it was rejected by the WG at the 64th IETF.

Here's a proposal for option 1. I am fully aware that I am doing amateur
cryptography.

3.2.5.  Obtaining Nonces

   The RADIUS client has three ways to obtain nonces: it generates them
   locally, it has received one in a Digest-Nextnonce attribute of a
   previously received Access-Accept packet, or it asks the RADIUS
   server for one.  To do the latter, it sends an Access-Request
   containing a Digest-Method and a Digest-URI attribute but without a
   Digest-Nonce attribute.  It adds a Message-Authenticator (see
   [RFC3579]) attribute to the Access-Request packet.  The RADIUS server
   chooses a nonce and responds with an Access-Challenge containing a
   Digest-Nonce attribute.

   The RADIUS client constructs a (Proxy-)Authenticate header using the
   received Digest-Nonce and Digest-Realm attributes to fill the nonce
   and realm directives.  The RADIUS server can send Digest-Qop, Digest-
   Algorithm, Digest-Domain and Digest-Opaque attributes in the Access-
   Challenge carrying the nonce.  If these attributes are present, the
   client MUST use them.

   If the RADIUS client generates nonces, the nonce must contain a time-
   stamp.  The nonce is constructed as follows:

         nonce = base64(concat(ts, hn(concat(random-pad, ts), secret)))

         where

         'base64(x)' encodes string x in base64 (see [RFC3548])

         'concat(a, b)' appends string b to string a

         'ts' is an unsigned integer of 4 bytes in network byte order
         with the number of seconds since January 1, 1970 00:00 UTC.

         'secret' is the shared secret between RADIUS client and server

         'hn(secret, message)' produces a hash of 'message' using the
         pass phrase 'secret'. 'hn' is the HMAC MD5 function described
         in [RFC2104].

         'random-pad' is a string of 56 random characters that is
         uniquely generated for each nonce.

   The time-stamp enables the RADIUS server to reject replayed nonces.
   The clock difference between RADIUS client and RADIUS server MUST NOT
   exceed 10 s.
[...]
3.3.2.  Determining the Age of the Nonce

   If the RADIUS server generates nonces, it will determine the age of a
   nonce by using an embedded time-stamp, or by looking it up in a local
   table.  The RADIUS server MUST check the integrity of the nonce, if
   it embeds the time-stamp in the nonce.  Section 3.3.3 describes how
   the server handles old nonces.

   If the RADIUS client generates nonces, the RADIUS server checks the
   the embedded time-stamp.  The RADIUS server responds to an Access-
   Request with a nonce that is too old or too young with an Access-
   Reject packet.  RADIUS servers logging rejected requests should
   include a hint to the operator that a too big clock difference caused
   the rejection.

   A nonce is considered too young if the received time-stamp is greater
   than the current time plus 11 s, allowing 1 s of packet delay.

   A nonce is considered too old if the received time-stamp is less than
   the current time minus 9 s, allowing 1 s of packet delay.


Wolfgang

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