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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Sun, 25 November 2012 01:19 UTC

Return-Path: <jsalowey@cisco.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 D4C6721F8594; Sat, 24 Nov 2012 17:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lqWnaVF-1ULu; Sat, 24 Nov 2012 17:19:46 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 168B621F8550; Sat, 24 Nov 2012 17:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2179; q=dns/txt; s=iport; t=1353806386; x=1355015986; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=t6nI5hX0Ag2vqPBNl0JPeeuO4dJ7nvHMqLk+Dh2AZAs=; b=j9Cxv9TfUtxVEzaNW65+xpzdHfwaL43+MEswJnLalpNU2/USCMsWQQwz 0ZMU6P8khRPGwVGY6R9QEa52JQl/ZAXrjSSPf6vm2bAribz1E3GzBCvxn 24sQBcw8uHVo832iZXLEZTNXzTnMQ6UO8/XsZ3q6B1Llt/6XBtD3AGp5N M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EADRxsVCtJV2Z/2dsb2JhbABEwD0Wc4IgAQQ6UQEqFEInBAEaiAW9J5AXYQOmRYJvgh0
X-IronPort-AV: E=McAfee;i="5400,1158,6906"; a="145599475"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 25 Nov 2012 01:19:45 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAP1Jjbm012440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 25 Nov 2012 01:19:45 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.63]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Sat, 24 Nov 2012 19:19:45 -0600
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" <draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-softwire-6rd-radius-attrib-07
Thread-Index: AQHNyqrzvpodTOJq1EuwowbWoRgUow==
Date: Sun, 25 Nov 2012 01:19:44 +0000
Message-ID: <A95B4818FD85874D8F16607F1AC7C62888F833@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.147]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B2DAEC9AE59A8A4F9640675448E3A336@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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 01:19:47 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I believe the document is almost ready for publication.  

The following are significant issues that need to be addressed:

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.  

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.  

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.   

Cheers,

Joe