[Dime] draft-ietf-dime-ikev2-psk-diameter open issues

"Cakulev, Violeta (Violeta)" <violeta.cakulev@alcatel-lucent.com> Tue, 23 November 2010 19:21 UTC

Return-Path: <violeta.cakulev@alcatel-lucent.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E488328C11B for <dime@core3.amsl.com>; Tue, 23 Nov 2010 11:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywvQiITszkTV for <dime@core3.amsl.com>; Tue, 23 Nov 2010 11:21:56 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1F10528C19A for <dime@ietf.org>; Tue, 23 Nov 2010 11:21:54 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id oANJMosH016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dime@ietf.org>; Tue, 23 Nov 2010 13:22:51 -0600 (CST)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oANJMnnB001373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dime@ietf.org>; Tue, 23 Nov 2010 13:22:50 -0600
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 23 Nov 2010 13:22:50 -0600
From: "Cakulev, Violeta (Violeta)" <violeta.cakulev@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Date: Tue, 23 Nov 2010 13:22:49 -0600
Thread-Topic: draft-ietf-dime-ikev2-psk-diameter open issues
Thread-Index: AcuLQ9CxAqrvWsfWTOCST+oPB8lq0A==
Message-ID: <AAE76B481E7A0E4C96610790A852B9A62508045DC7@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 19:21:58 -0000

As discussed in Beijing meeting, there are 2 open issues. These open issues and their respective solutions are summarized below.

----------------------------------------------------------------------------------------
Issue 1. Is there any need for Auth-Request-Type AVP in the request if only Authorize-Only (value 2) is used in this application? What should be the behavior of the receiver if the Auth-Request-Type AVP is set to the value 1 or 3, which are valid values? What is the error code send back to the sender?

Solution to issue 1: Keep Auth-Request-Type AVP in the request with only Authorize-Only (value 2) allowed. If values 1 or 3 are received send Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP in the Failed-AVP AVP. DIAMETER_INVALID_AVP_VALUE is a permanent failure, therefore the peer is informed that the request failed, and should not be attempted again. Values 1 and 3 are valid values in Diameter based protocol, however they are invalid values in this I-D, therefore there are no problems to send DIAMETER_INVALID_AVP_VALUE if 1 or 3 are received.
----------------------------------------------------------------------------------------

Issue 2: When IKEv2 Server requests the key it may use SPI to help AAA determine which key needs to be returned. How is this SPI transported to AAA?
This issue has multiple solutions. Some of the solutions are outlined below. Interested parties are invited to indicate preferred solution.

Solution 1: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains only SPI AVP. In this case, draft-ietf-dime-local-keytran is modified such that Keying-Material AVP is optional AVP.

Solution 2: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains both Keying-Material AVP and SPI AVP. Keying-Material AVP is populated with all 0s and/or is ignored by AAA. In this case, no changes to draft-ietf-dime-local-keytran are needed.

Solution 3: Do not use draft-ietf-dime-local-keytran and specify all AVPs in this I-D.

Solution 4: Specify SPI AVP in this I-D and send it separately in the request. Use Key AVP specified in draft-ietf-dime-local-keytran in the response.
-----------------------------------------------------------------------------------------


Best regards,
-Violeta