Re: [Ace] Offline operation of Resource Server

Rafa Marin Lopez <rafa@um.es> Tue, 15 July 2014 15:36 UTC

Return-Path: <rafa@um.es>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E31B28BA for <ace@ietfa.amsl.com>; Tue, 15 Jul 2014 08:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJVC5XFkTW5M for <ace@ietfa.amsl.com>; Tue, 15 Jul 2014 08:36:28 -0700 (PDT)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 1229E1B2883 for <ace@ietf.org>; Tue, 15 Jul 2014 08:36:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id B167FBC58; Tue, 15 Jul 2014 17:36:26 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HrMzTkLfjMiF; Tue, 15 Jul 2014 17:36:26 +0200 (CEST)
Received: from [192.168.1.66] (214.Red-83-42-243.dynamicIP.rima-tde.net [83.42.243.214]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id 75124EDC; Tue, 15 Jul 2014 17:36:24 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <18172.1405438034@sandelman.ca>
Date: Tue, 15 Jul 2014 17:36:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D537FA0-1FCF-42D0-B5C1-FB45E00E6332@um.es>
References: <53C3C09A.5090707@gmx.net> <14018.1405360899@sandelman.ca> <53C42703.4060806@gmx.net> <8236.1405368736@sandelman.ca> <53C4C082.3020909@sics.se> <191F7113-E5ED-49A2-AC27-AA886D527FB1@um.es> <18172.1405438034@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/flnAc-mXgcQ4MxTitUsNsiFqt0Y
Cc: ace@ietf.org
Subject: Re: [Ace] Offline operation of Resource Server
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 15:36:31 -0000

Hi Michael:

El 15/07/2014, a las 17:27, Michael Richardson <mcr+ietf@sandelman.ca> escribió:

> 
> Rafa Marin Lopez <rafa@um.es> wrote:
>> That is possible if during the EAP/AAA interactions there is a
>> bootstrapping of some short term credential (e.g. Kerberos
>> tickets). For example, if we talk in Kerberos terminology, the
> 
> Please don't build in any assumption in your thinking that the resulting
> ticket is short term.  Some may wish it; but for many applications we are
> talking about tickets that either never expire, or have expirations times
> decades in the future.

I agree. I was talking about a typical case in Kerberos. But I do not have problem with having long-term credentials bootstrapped. That should be feasible. Nevertheless, please take into account that the bootstrapping phase might be used only once for decades (so the source code developed for it). 

> 
> Josh Howlett <Josh.Howlett@ja.net> wrote:
>>> So, in summary, there could be an online enrollment and online
>>> authorization decision based on EAP/AAA that allows to bootstrap
>>> "something" that enables RS and C to have an offline interaction during a
>>> period of time (e.g. ticket lifetime).
> 
>> Just by way of example, another "something" that could be bootstrapped
>> by EAP/AAA (as an alternative or complement to a Kerberos ticket) could
>> be a certificate. There is also running code demonstrating this.
> 
> Yes; exactly.  The certificate could contain Authorization Attributes rather
> than identities.  Anyone who hasn't read rfc2692 and rfc2693 lately, should
> do so.
> 
> Just think of the kerberos-like symmetric key token as being a certificate
> that can only be validated by the originator.

In fact, we have also considered the case of bootstrapping a certificate after an EAP/AAA authentication. So I have no problem at all with that. So +1 to that.

Best Regards.

> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------