Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00

From: Ludwig Seitz <[email-masked]>
Date: Tue, 17 Nov 2015 12:01:49 +0100

Hello Madjid,

sorry for the long delay in answering, I had to tie up numerous loose 
ends from other projects after IETF 94.

Answers inline.

/Ludwig

On 2015-10-30 22:05, Madjid Nakhjiri wrote:
> Hi Ludwig,
>
> Regarding
>
> "You seem to have experience with specific issues in that matter, could
> you describe those issues in more detail?”
>
> I appreciate your inquiry for me to be frank, so let me provide a couple
> of broad answers:
>
> 1) I am involved with at least 3 standards who either are struggling or
> working hard to solve the onboarding/ provisioning problems or IOT type
> environments.
[...]

ACE has not considered this issue so far. One assumption I overheard was 
that the device would come with some barcode or other printed id that 
would identify a key to be used for bootstrapping. Another assumption 
was that proximity based mechanisms might be used for a leap-of-faith 
like onboarding procedure.

There is some scientific work on that problem by Frank Stajano and Ross 
Anderson (start here 
https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf), on 
a cursory glance they seem to propose contact (such as connecting to the 
device with a cable) as one solution
(which seems close to the proximity solution I overheard).

> 2) I am interested in figuring out what sort of support HW vendors like
> Mediatek need to provide for supporting authorization mechanisms such as
> OAUTH.
>

For OAuth, I would guess that support for proof-of-possession tokens is 
a good start. This can be done both with symmetric and asymmetric crypto.

This would mean that hardware AES would be a priority.

SHA-2 or SHA-3 for HMAC, signature algorithms and key derivation 
functions is probably also a good idea.

Elliptic curve crypto support is propably what you want if the use cases 
require asymmetric cyrpto (e.g. for signatures).

Access to reliable time measurements impacts a lot how expiration, 
replay-protection and freshness can be provided, so a RTC is also nice 
to have.

I guess mostly it's a question of pricing for mass deployments, how much 
can the HW cost vs. what (crypto-)functions does it provide.

Anyone spotting something obvious I missed here?

[...]
>> NOTE: ACE is explicitly not chartered to work with key management and
>> the word has been shunned from any document, therefore I do not expect
>> that ACE will work on that issue.
>
> Madjid>>fair enough. Is there any other place in IETF that deals with it?
>
None that I'm aware of.

>>
>>
>>>   2. Same thing for RS to AS registration. RS is many times a constrained
>>>      device itself. Also I am not clear how the AS will get the
>>>      authorization policies (scope/claim?) from RS. Is it that it is the
>>>      AS that decides??
>>
>>
>> Actually it was never planned that the itself RS should provide and
>> manage the authorization policies at the AS. The resource owners are
>> expected to do this at the AS directly, when they enroll a RS they own.
>
> Madjid>>Ok, makes sense. Are the policy definitions standardized? Or up to
> each vendor?
>

No the policies are not standardized in ACE. I don't think that would 
make much sense unless policies need to be exchanged between several 
federated AS. In that case there are policy standards that could be used 
such as XACML, but that is definitely not an ACE matter since the AS are 
expected to be unconstrained.

[...]
>>>   4. Restrospection of the tokens can be expensive and unscalable for the
>>>      AS (if there are many RS nodes), but verification of self-contained
>>>      tokens by the RS also sounds expensive, plus the verification keys
>>>      need to be provisioned in the RS. Would be nice to have guidance on
>>>      which makes sense taking device capabilities/class into account. Any
>>>      network simulators out there?
>>
>> I'm guessing you meant Introspection here right?
>>
>> The AS is not expected to be a constrained device, thus it should be
>> able to serve a significant number of introspection requests from
>> different RS. Introspection works best if the RS has a good connectivity
>> to the AS while the client has intermittent connectivity or simply
>> connectivity for the client is expensive (e.g. costs a lot of battery).
>> Of course the number of AS has to be scaled up with the number of RS,
>> but I don't think that is any different for non-constrained scenarios.
>
> Madjid>>Yes, Introspection, sorry.
> You are assuming that AS is in the cloud? Or within the “local”
> environment? I guess, if in the cloud, then scalability should be no
> issue.
 > If local, then the volume should be low, which also ok.

No specific assumptions on the AS here. The sole assumption for this 
usecase is that the client has no connectivity after being deployed.

> Either way, the assumption of introspection is that the cost of sending a
> token back to AS is lower than verifying it locally. The question is how
> do know the verification actually came from AS? Are you assuming a
> persistent TLS/ DTLS (if there is such a thing) connection to avoid
> message integrity verification costs?

Since the client has no connectivity in this case, it needs a long-lived 
token. This means that you do not want to bind specific rights to that 
token when it is issued (such as e.g. a specific scope).
This means that the RS _can not_ verify the token locally.

There is a cost saving aspect here as well since the token can be made 
very compact (it's just a reference that the AS uses to look up the 
client's access rights in the introspection). This saves transmission 
volume in the communication between client and RS.

>
>>
>> Verifying a self-contained token certainly can be expensive, but the
>> alternative is to be connected to the network in order to get a
>> real-time access control decision from an AS.
>>
>> We assume roughly the following "hierarchy" of costs (from most
>> expensive to least):
>>
>> 1. Network traffic (sending/receiving/listening for incoming messages)
>> 2. Crypto operations
>> 3. Matching requests against permissions granted by access tokens
>
>

>> Several experiments I conducted have shown that 3. is almost negligible
>> when compared to the cost of 2. and 1.  When you add the overhead of
>> running a security protocol when doing network communication, this makes
>> both 2. & 3. very cheap compared with 1.
>
> Madjid>>Interesting. So what is the metric for cost? CPU cycles? Time
> spent in a task lock? What sort of OS you have in mind? OS or RTOS?
> I would love to see any paper or info on the experiments you conducted.

I think it's not very surprising, since matching the requests to tokens 
will usually just require a few comparisons (strings, integers, binary, 
and perhaps regexp at worst), while crypto involves some heavy 
calculations (AES takes 10 rounds of transformations for 128 bit keys 
for example).

I have supervised two masters thesis projects that have some results to 
that effect.

*http://soda.swedish-ict.se/5684/1/NiklasHjern_JonasVistrand_Master_Thesis_EIT.pdf

This is a project using a token-based authorization approach (not OAuth) 
and TLS. From the figures in section 6 you can see that transmitting the 
token is by far the most expensive part (red parts of the figures) while 
processing TLS vs TLS+matching requests against tokens is almost 
indistinguishable.

* http://soda.swedish-ict.se/5681/1/Thesis._AC_in_the_IoT._Final.pdf

This is a project using a key derivation method to provision pre-shared 
keys via a trusted third party (based on 
draft-seitz-core-security-modes-00). Here it is shown that a key 
derivation (including some Base64 decoding and SHA-2 calculations) is 
almost negligible in comparison to a DTLS handshake. If you want to 
extend this to generic message exchanges, the key derivation is roughly
equivalent to sending a ClientHello message (compare tables 7.1 and 7.2|).

http://soda.swedish-ict.se/5681/1/Thesis._AC_in_the_IoT._Final.pdf

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se