Re: [Ace] Reg: Questions about ace-oauth-authz-09.

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 13 February 2018 07:44 UTC

Return-Path: <ludwig.seitz@ri.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E112E88E for <ace@ietfa.amsl.com>; Mon, 12 Feb 2018 23:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3_dh8GrTkkPo for <ace@ietfa.amsl.com>; Mon, 12 Feb 2018 23:44:33 -0800 (PST)
Received: from se-out1.mx-wecloud.net (se-out1.mx-wecloud.net [89.221.255.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CCF12E88A for <ace@ietf.org>; Mon, 12 Feb 2018 23:44:32 -0800 (PST)
Received: from sp-mail-2.sp.se (unknown [194.218.146.197]) by se-out1.mx-wecloud.net (Postfix) with ESMTPS id E58612056DB; Tue, 13 Feb 2018 07:44:28 +0000 (UTC)
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 13 Feb 2018 08:44:29 +0100
To: ace@ietf.org, PAVAN YADAV 16MCA1050 <pavan.yadav2016@vitstudent.ac.in>
References: <CAAnkS-f_yFeasEq4SekopVeqgUVDxm1Fz5EZJ25kfxvV5Yabvw@mail.gmail.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <f18e86af-868c-729f-88e2-4ce4cf6563b7@ri.se>
Date: Tue, 13 Feb 2018 08:44:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAAnkS-f_yFeasEq4SekopVeqgUVDxm1Fz5EZJ25kfxvV5Yabvw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.2 cv=cdiiljLM c=1 sm=1 tr=0 a=L5DDne6A+dD0FbDkt2Fblw==:117 a=L5DDne6A+dD0FbDkt2Fblw==:17 a=sZ8rJzgPlrQA:10 a=IkcTkHD0fZMA:10 a=Op4juWPpsa0A:10 a=mx4nZK4EWs2G89x58GgA:9 a=mEfE2-3I2eIYEj8d:21 a=m1zwTJjgajYpO51J:21 a=QEXdDO2ut3YA:10
X-Virus-Scanned: clamav-milter 0.99.3 at MailSecurity
X-Virus-Status: Clean
X-MailSecurity-Status: 0
X-Scanned-By: WeCloud MailSecurity
X-MailSecurity-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/cKV-J5scxFkHcdbxlknAXlPa8qI>
Subject: Re: [Ace] Reg: Questions about ace-oauth-authz-09.
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Feb 2018 07:44:35 -0000

On 2018-02-12 20:03, PAVAN YADAV 16MCA1050 wrote:
> How many resources can be connected to the resource server? Is there any 
> limitation?
> 

There is no limitation in the standards draft, you probably have some 
hardware limitations, but these are dependent on the specific device you 
are deploying the ACE framework on.


> What is the max time limit for an access token for clien.

Again no limit in the draft. It's implementation dependent.
In my code I made that a unsigned long (i.e. up to 2^64-1 ms).

... but: This is just the implementation limit, since we are dealing 
with constrained environments, where tokens and the corresponding pop 
key can get stolen, keeping the lifetime short is probably a good idea 
in general.

> What will be the bit size of Proof-of-Possession digital token and key?

The size of the token depends on several parameters:

1.) If it is a CWT or something else (e.g. just a reference)
2.) If it is a CWT: what kind of COSE wrapper it has
3.) If it is a CWT: what claims does the token contain

You will get the smallest token size by just using a reference (but then 
the RS needs to do introspection or know the tokens beforehand).

If you need a compact CWT, using some symmetric key wrapper (MAC or 
Encrypt) will help you, and minimizing the number of claims (perhaps you 
can have some default claims that all involved parties know beforehand, 
like e.g. the profile they are using).

As a ballpark number, I create some CWT's in my junit tests that are 
roughly 200 bytes large. They contain a lot of claims including a public 
key, so that's probably at the larger end of the scale.


Size of the key depends on how your are performing the 
proof-of-possession. If you e.g. use DTLS-PSK you would typically use a 
128 bit AES key.


Hope that helps

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51