Subject: [AAA-WG]: [DSA]: Generation of nonces

From: Miguel Garcia <[email-masked]>
Date: Fri, 10 Mar 2006 15:21:58 +0200

As you may know, the Diameter SIP application is under IESG review. 
There have been some comments that you can follow in the data tracker:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10945&rfc_flag=0

The important comment is originated by the Security ADs: there is an 
issue with the generation of nonces in the client. The issue was first 
identified in the RADIUS extension for HTTP/SIP authentication, and the 
resolution should be unique for both RADIUS and Diameter. The exact 
issue is recorded here:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=43578

The RADIUS draft was re-issued recently, and already tried to address 
this issue by providing an known algorithm for creating and verifying 
nonces. This hasn't been revised by the Security ADs yet, so it is 
unknown at this stage if this clears that discuss or not. But just in 
case it clears it, we may need to add similar wording to the Diameter 
SIP application.

So, I would like that the AAA group reviews a couple of sections of the 
RADIUS Digest draft to find out if we are ok with the nonce generation 
guidelines. If we find no objections and if this is ok to the Security 
ADs, we will add it to the Diameter document.

The latest version of the RADIUS Digest draft is:

http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-07.txt

Sections that are relevant for the nonce generation in the client are 
3.2.5 and 3.3.2.

Please, comment and speak if you have problems. Copy Wolfgang in the 
discussion.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Tue, 28 Mar 2006 17:36:47 +0200

> case it clears it, we may need to add similar wording to the Diameter 
People didn't like that algorithm too much. The conclusion at the RADEXT
meeting in Dallas was to remove the RADIUS/Diameter client nonce
generation entirely. Without that mode, the security issue vanishes. The
AAA server itself can check the nonce validity using the scheme proposed
in RfC 2617 3.2.1

As RfC 2617 uses the challenge message not only to convey the nonce
but some capability information (like supported digest algorithms),
AAA client nonce generation requires additional manual configuration.

Removing that mode would improve the drafts.

Wolfgang

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