Re: [Dime] Review of draft-ietf-dime-local-keytran-03

Tom Taylor <tom111.taylor@bell.net> Thu, 13 May 2010 13:01 UTC

Return-Path: <tom111.taylor@bell.net>
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 015313A6892 for <dime@core3.amsl.com>; Thu, 13 May 2010 06:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.898
X-Spam-Level:
X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803]
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 XDSF69898zXC for <dime@core3.amsl.com>; Thu, 13 May 2010 06:01:41 -0700 (PDT)
Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by core3.amsl.com (Postfix) with ESMTP id 445E83A681E for <dime@ietf.org>; Thu, 13 May 2010 06:01:37 -0700 (PDT)
Received: from BLU0-SMTP13 ([65.55.116.72]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 06:01:27 -0700
X-Originating-IP: [70.26.23.183]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: <BLU0-SMTP1379FA02B7E014A72ABF23D8FC0@phx.gbl>
Received: from [192.168.2.11] ([70.26.23.183]) by BLU0-SMTP13.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 06:01:27 -0700
Date: Thu, 13 May 2010 09:01:23 -0400
From: Tom Taylor <tom111.taylor@bell.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43AE83@xmb-sjc-225.amer.cisco.com> <00b701caedc5$92e4d150$b8ae73f0$@net> <AC1CFD94F59A264488DC2BEC3E890DE50A554125@xmb-sjc-225.amer.cisco.com> <000401caf25d$420b7d50$c62277f0$@net>
In-Reply-To: <000401caf25d$420b7d50$c62277f0$@net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 May 2010 13:01:27.0261 (UTC) FILETIME=[65F140D0:01CAF29C]
Cc: dime@ietf.org
Subject: Re: [Dime] Review of draft-ietf-dime-local-keytran-03
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: Thu, 13 May 2010 13:01:42 -0000

Below.

Glen Zorn wrote:
> Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] writes:
> 
>>> 1.       Key types -  The document lists USRK and DSUSRK as key types.
>>> These are a class of keys and do not necessarily refer to a specific
>>> application.  How would one represent different USRKs for different
>>> usages?  Are rMSK and rRK examples of USRKs?
>>>
>>> Any recommendations?
>> [Joe] Right now key type is representing both a class of key
>> (USRK,DSUSRK,etc) and a specific application and usage of key material
>> (rMSK and rRK).    For example an rRK may either be a USRK or a DSUSRK.
>> There are several ways you could do this differently.
>>
>> a) Flatten out the space - get rid of USRK, DSUSRK - include rRK, rMSK,
>> MSK, DSRK, IKEv2 PSK.  Add a domain AVP that would be included if the
>> key is a DSRK or an instance of a DSUSRK.  This would contain the domain
>> that was used in the key derivation (perhaps this is always know, but
>> maybe a server can server more than one domain).
> 
> Tom Taylor mentioned this as well but I am still puzzled by it: in what
> scenario could this occur?  AFAIK all the keys are bound to a particular
> session which is itself bound to a particular access point.  What am I
> missing?
> 
> ...
[PTT]
OK, this is one for the architecture to answer. I'll review the different 
interfaces to see if there is a case of anticipatory keying that isn't bound as 
tightly as you suggest. At the very least, I don't think the keys passed to a 
local ER server would be bound to a particular access point, but they may indeed 
be bound to a particular session, in some sense of session.