[AAA-WG]: drafts-sterman-aaa-sip-04 is available
"Beck01, Wolfgang" <BeckW@t-systems.com> Fri, 22 October 2004 07:54 UTC
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09748 for <aaa-archive@lists.ietf.org>; Fri, 22 Oct 2004 03:54:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E38DB9121F; Fri, 22 Oct 2004 03:54:00 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B125D91285; Fri, 22 Oct 2004 03:54:00 -0400 (EDT)
Delivered-To: aaa-wg@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 358EA9121F for <aaa-wg@trapdoor.merit.edu>; Fri, 22 Oct 2004 03:53:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 15AFFB1E20; Fri, 22 Oct 2004 03:53:59 -0400 (EDT)
Delivered-To: aaa-wg@merit.edu
Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 52C01B1E12 for <aaa-wg@merit.edu>; Fri, 22 Oct 2004 03:53:58 -0400 (EDT)
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 22 Oct 2004 09:53:48 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <VD55WKQD>; Fri, 22 Oct 2004 09:53:46 +0200
Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FDD1@E9JDF.mgb01.telekom.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: radiusext@ops.ietf.org, aaa-wg@merit.edu
Cc: miguel.an.garcia@nokia.com
Subject: [AAA-WG]: drafts-sterman-aaa-sip-04 is available
Date: Fri, 22 Oct 2004 09:53:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-wg@merit.edu
Precedence: bulk
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
- [AAA-WG]: drafts-sterman-aaa-sip-04 is available Beck01, Wolfgang