Re: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07

Alan DeKok <aland@deployingradius.com> Sun, 25 November 2012 14:18 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B290721F84D5; Sun, 25 Nov 2012 06:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj++bYH214zc; Sun, 25 Nov 2012 06:18:08 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E288821F8466; Sun, 25 Nov 2012 06:18:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0DB9D22408BE; Sun, 25 Nov 2012 15:18:04 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSclztXGp-vd; Sun, 25 Nov 2012 15:18:03 +0100 (CET)
Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id BD02922403DE; Sun, 25 Nov 2012 15:18:02 +0100 (CET)
Message-ID: <50B2289A.8060402@deployingradius.com>
Date: Sun, 25 Nov 2012 09:18:02 -0500
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <A95B4818FD85874D8F16607F1AC7C62888F833@xmb-rcd-x09.cisco.com>
In-Reply-To: <A95B4818FD85874D8F16607F1AC7C62888F833@xmb-rcd-x09.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: The IESG <iesg@ietf.org>, "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" <draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Nov 2012 14:18:08 -0000

Joseph Salowey (jsalowey) wrote:
> 1.  A RADIUS message used for call-check does not contain any information that would authenticate the request.  Therefore RADIUS messages using the 6rd attribute MUST include a message-authenticator attribute or another attribute that is capable of authenticating the RAIDUS packet.  

  I missed that.  I agree with the requirement for a Message-Authenticator.

> 2.   I'm not so familiar with the deployment scenario here so I have a question.  Is it possible that the BNG was involved in a previous transaction with the AAA server to authenticate a user?   If this is the case then the BNG may have received a state attribute in the access-accept message.   Returning this state attribute to the AAA server allows the AAA server to link the 6rd request with the original authentication transaction.    If this is a possible scenario the document should specify this since state attributes are not typically used with the call-check service.  Also if its the case that there could have been a related previous authentication session it seems that it should be possible to include this attribute in an access-request as part of the authentication exchange.  

  I *think* that the answer here is "no".  The document previously used
Service-Type = Authorize-Only and a State attribute.  After some
discussion, it was decided to change that to Call-Check, because there
was no way to obtain a State attribute.

> 3.  It was not clear in the specification what is sent in the access-request message is the BNG is looking to get a IPv6-6rd-configuration attribute in the access accept.  It seems that you would need to send this attribute in the request if you expected it in the response or else the AAA server would not be able to un ambiguously be able to service the request; there are other uses for the call-check service.   I think you should specify that the 6rd attribute must be in the request if you want to see it in the response.   

  That would probably be good.