Re: [Ace] Offline operation of Resource Server
Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 14 July 2014 18:52 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 DF3CD1A0065 for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 11:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kQhMikiRJUWw for <ace@ietfa.amsl.com>; Mon, 14 Jul 2014 11:52:55 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978CD1A0061 for <ace@ietf.org>; Mon, 14 Jul 2014 11:52:55 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBnvD-1XFFII0Mv1-00An3F; Mon, 14 Jul 2014 20:52:53 +0200
Message-ID: <53C42703.4060806@gmx.net>
Date: Mon, 14 Jul 2014 20:52:51 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <53C3C09A.5090707@gmx.net> <14018.1405360899@sandelman.ca>
In-Reply-To: <14018.1405360899@sandelman.ca>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="qvgkFDk67gCaOfcJUvgHWLmTcbtm4ATsc"
X-Provags-ID: V03:K0:R2qJS7h4/L2HF1rMM2e/rfI279IgsofUXvWK7vRsDdlezrA6I5Q J6/GpY2MboVxJT4+SOqEWLVJsuRS6LujJZOedHGxXDRJgwTt6i5eSwRIAvi+URNh5dvlFtx UxrLl3MUNeZ58CeeD/XgRy1KN/LJjKRjqrSSYSh8vQpLsHIU+uK9Mm/yPIk6pMxELEuMl+t HhNiXTBgG2qyYK78Tud5Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/ace/UdleBzMPsT0IKEg6JL5311mwIJI
Cc: "ace@ietf.org" <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: Mon, 14 Jul 2014 18:52:59 -0000
To re-use the Kerberos language, the client gets the TGT. The real-time interaction I was talking about relates to the interaction between the resource server and the authorization server. Maybe the language in the use case document needs to be a bit more explicit. Ludwig, could you please explain this offline requirement a bit more? Ciao Hannes On 07/14/2014 08:01 PM, Michael Richardson wrote: > > Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote: > > in one of my previous mail I said that the requirements rule out an > > EAP/AAA solution and this impression was based on reading the following > > requirement from http://tools.ietf.org/html/draft-seitz-ace-usecases-01 > > > " > > o U5.2 The meters must be able to perform fine-grained access > > control on the metering data and on the configuration while being > > offline. > > " > > > I was wondering how strong the requirement for not having a real-time > > interaction between the resource server and the AS is. > > I think it is important to have the tokens able to be validated offline > within some deployment specific time interval. For some deployment "99 > years" is exactly what is desired, for other deployments having to be online > is what is desired. > > The missing piece is enrollment of devices (must be online), and associated > with that is the initial exchange of authorization tokens. > > My view is that "enrollment" is really about establishment of the "superuser" > authorization token in the AS. In kerberos terms, it's the Ticket Granting > Ticket. > > -- > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > >
- [Ace] Offline operation of Resource Server Hannes Tschofenig
- Re: [Ace] Offline operation of Resource Server Josh Howlett
- Re: [Ace] Offline operation of Resource Server Hannes Tschofenig
- Re: [Ace] Offline operation of Resource Server Rafa Marin Lopez
- Re: [Ace] Offline operation of Resource Server Michael Richardson
- Re: [Ace] Offline operation of Resource Server Hannes Tschofenig
- Re: [Ace] Offline operation of Resource Server Michael Richardson
- Re: [Ace] Offline operation of Resource Server Ludwig Seitz
- Re: [Ace] Offline operation of Resource Server Göran Selander
- Re: [Ace] Offline operation of Resource Server Kumar, Sandeep
- Re: [Ace] Offline operation of Resource Server Likepeng
- Re: [Ace] Offline operation of Resource Server Ludwig Seitz
- Re: [Ace] Offline operation of Resource Server Hannes Tschofenig
- Re: [Ace] Offline operation of Resource Server Rafa Marin Lopez
- Re: [Ace] Offline operation of Resource Server Josh Howlett
- Re: [Ace] Offline operation of Resource Server Michael Richardson
- Re: [Ace] Offline operation of Resource Server Michael Richardson
- Re: [Ace] Offline operation of Resource Server Rafa Marin Lopez
- Re: [Ace] Offline operation of Resource Server Ludwig Seitz