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 =-
> 
> 
>