Re: [AAA-WG]: issue with expected response calculation
Jo Hermans <jo.hermans@gmail.com> Tue, 12 April 2005 22:45 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 SAA20591 for <aaa-archive@lists.ietf.org>; Tue, 12 Apr 2005 18:45:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C6FBD912F1; Tue, 12 Apr 2005 18:45:26 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CC13912F6; Tue, 12 Apr 2005 18:45:26 -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 BC337912F1 for <aaa-wg@trapdoor.merit.edu>; Tue, 12 Apr 2005 18:45:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9F9D75828A; Tue, 12 Apr 2005 18:45:21 -0400 (EDT)
Delivered-To: aaa-wg@segue.merit.edu
Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 83FB058285 for <aaa-wg@segue.merit.edu>; Tue, 12 Apr 2005 18:45:21 -0400 (EDT)
Received: by testbed9.merit.edu (Postfix) id 8AB1C185B; Tue, 12 Apr 2005 18:45:21 -0400 (EDT)
Delivered-To: aaa-wg@merit.edu
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by testbed9.merit.edu (Postfix) with ESMTP id 3A3D41863 for <aaa-wg@merit.edu>; Tue, 12 Apr 2005 18:45:20 -0400 (EDT)
Received: by wproxy.gmail.com with SMTP id 67so3753202wri for <aaa-wg@merit.edu>; Tue, 12 Apr 2005 15:45:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=JI1tM8FF96ReF2jT/kkZE2CY759XHSR14LuZxpJ6qLuZFlxQYRQD9JwrM4+2FT/L3xJQjuZQyBv/5h3Shc+gVz3DTA0r4b3+M84Sgb58RzVCm3xSMQNbmeI34r012HD4S0AsYs6q/yup2zjgDdvs9kTLVdBfxkCjH5NVOzJf1WE=
Received: by 10.54.43.78 with SMTP id q78mr1524622wrq; Tue, 12 Apr 2005 15:44:20 -0700 (PDT)
Received: by 10.54.43.21 with HTTP; Tue, 12 Apr 2005 15:44:15 -0700 (PDT)
Message-ID: <a4ba2af605041215447164d6ce@mail.gmail.com>
Date: Wed, 13 Apr 2005 00:44:15 +0200
From: Jo Hermans <jo.hermans@gmail.com>
Reply-To: Jo Hermans <jo.hermans@gmail.com>
To: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: issue with expected response calculation
In-Reply-To: <a4ba2af605041205262c911cf6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_13_16954606.1113345855892"
References: <a4ba2af605041205262c911cf6@mail.gmail.com>
Sender: owner-aaa-wg@merit.edu
Precedence: bulk
Replying on my own question ... On 4/12/05, Jo Hermans <jo.hermans@gmail.com> wrote: > > I have a problem with paragraph 8.5.6.1 <http://8.5.6.1> in > draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the > expected response ...") > > The draft mentions that the expected response calculation can't be done > when the SIP UA has sent a expected response based on client nonces. It then > mentions that this is the case when the qop-parameter is present in the > client request. > > That last part I don't understand. I though that H(A1) is dependent on the > algorithm, not qop. Qop has only influence on the A2 and digest, which are > both calculated in the Diameter Client (SIP Server). See also < > http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40> > > But even then I don't understand. I think that the Diameter Server does > has the client-nonces available (they're in the SIP-Authorization AVP, and > were used to calculate the request digest !)), and is able to calculate a > H(A1). Even if MD5-sess was used, it could still calculate H(A1). MD5-sess > also has the added advantage that H(A1) could only be used once, which is > also the reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 > unless the message is protected against eavesdropping. Now I see that the Digest-HA1 attribute is present in the SIp-Authenticate AVP, which probably never saw a cnonce at all, because it's part of the challenge. My mistake was that I thought that it was in SIP-Authorisation too. This also means that if a server decides to include Digest-Ha1 to assist the SIP-server (to avoid that the next packet with the Sip-Authorisation should be forwarded to the server too), then it should not offer the SIP UA to use MD5-sess, because that includes client-nonces in A1. Qop is not a problem, despite paragraph 3 in section 8.5.6.1 <http://8.5.6.1> of sip-app-07. I agree that if qop is missing and algorithm is MD5, client-nonces aren't > used at all (backwards compatibility with RFC2069). H(A1) might be stored > inside the Diameter Client (SIP server) when it's first received, and reused > later on. Is it this that the draft is alluding to ? > > -- > Jo Hermans > > "Eagles may soar, but weasels aren't sucked into jet engines" -- Jo Hermans www.bluesweb.org <http://www.bluesweb.org> "Eagles may soar, but weasels aren't sucked into jet engines"