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

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 29 Oct 2015 01:09:52 +0000

Hi all, authors of the draft

I was asked to review by one of the authors and I did it last week. Unfortunately, I have not read all the drafts/ RFCs that the draft is referencing, and my knowledge of OAUTH is a few years old, so  I apologize for potential ignorance on that regard .

I think the draft is doing a good job of trying to create a “system solution” by bringing OAUTH, COAP, CBOR and the app layer security solutions together.

Issues that I see with the over all framework that still requires addressing (within IETF??):

  1.  provisioning of client keys for authentication and registration with the AS. Having a global key/ID in the client has been an issue for some OAUTH implementations in the past. Given that the clients are IoT devices, this is not as straight forward as mobile app clients.
  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??
  3.  Is authorization subject based (identity of client) or role based?
  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?
  5.  Wonder if the two app layer security solutions (OSCOAP/ OSCON) cover the provisioning of the keys they are using?
  6.  If COAP option max length is 256 bits, how can a signature mechanism that requires that many bits be used?

Regards,
Madjid Nakhjiri
麦志得
Principal Security Architect
MediaTek Inc.
“Simplicity is the ultimate sophistication"

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Oct 2015 10:24:28 +0900

Madjid Nakhjiri wrote:
> # If COAP option max length is 256 bits, how can a signature mechanism
> that requires that many bits be used?

It's not -- there is no fundamental limit to CoAP option size.
Practically speaking, however, it is often advantageous to be able to
put a CoAP message into a datagram that is of appropriate size.
RFC 7252 gives 1152 bytes as a practical upper bound of that; some
radios are much happier with 80 bytes or less (not excluding the
occasional larger message, but that might have a harder time getting
through, so you might want to use them sparingly).  Also note that the
CoAP block protocol helps with splitting up payloads into blocks, but
options do not benefit from that.

So the gist is: a 256-bit (32-byte) signature is quite possible in an
option; for some applications the burden such an option places on the
remaining message size is rather significant, but mostly not prohibitive.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 29 Oct 2015 10:44:23 +0100

Hello Madjid,

Thank you for providing your comments on our draft! Answers are inline.

/Ludwig

On 2015-10-29 02:09, Madjid Nakhjiri wrote:
[...]
>  1. provisioning of client keys for authentication and registration with
>     the AS. Having a global key/ID in the client has been an issue for
>     some OAUTH implementations in the past. Given that the clients are
>     IoT devices, this is not as straight forward as mobile app clients.

If I understand you correctly the problem is about having global IDs 
that clients and AS can use to reference keys.

I expect that in many cases the clients will only be served by a single 
AS (or a few ones at most), which means that the key management problem 
on that side is less difficult.

Since the AS will probably manage keys for many clients, the IDs need to 
be unique at least per AS. Therefore defining a namespace that is unique 
for a specific AS and prefixing the key ID with that namespace should 
work towards solving that problem.

You seem to have experience with specific issues in that matter, could 
you describe those issues in more detail?

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.

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

>  3. Is authorization subject based (identity of client) or role based?

The solution should work with both approaches. The client is expected to 
present credentials to the AS when requesting a token. These credentials 
can then be resolved to an identity, or a role, or some security 
attributes of the client. The AS is then expected to make an 
authorization decision based on the credentials and the existing 
authorization policies.

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

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.

>  5. Wonder if the two app layer security solutions (OSCOAP/ OSCON) cover
>     the provisioning of the keys they are using?

OSCOAP and OSCON are based on COSE, which in turn is based on JOSE 
(JWE/JWS).  JOSE and COSE have some key provisioning functionality

>     that requires that many bits be used?

Carsten has already answered that and I agree with his assessment.

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

---

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 29 Oct 2015 21:51:32 +0000

The good thing about building with existing protocols is that problems like this have already been thought of, implemented and solved :)

- RFC7591 is the "OAuth 2.0 Dynamic Client Registration Protocol” that describes how to bind new clients to any AS. That could be profiled for CoAP and CBOR in the same way as the OAuth2 for IoT drafts does.
- There is also the "OAuth 2.0 Resource Set Registration” work (https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06) in the oauth wg that gives the RS a way to bind it self to an AS dynamically and telling it exactly what it should protect. That too could be profiled if needed.
- UMA, builds on top of OAuth2, also introduced the claims gathering flows that lets an user/device authenticate it self using any type of claims/attributes/methods and it lets the system discover the proper way dynamically.

There are some good pieces out there to get authentication and authorization flows working in a dynamic and disperse connected world already.

/ Erik

On 29 Oct 2015, at 10:44, Ludwig Seitz <[email-masked]<mailto:[email-masked]>> wrote:

Hello Madjid,

/Ludwig

If I understand you correctly the problem is about having global IDs that clients and AS can use to reference keys.

I expect that in many cases the clients will only be served by a single AS (or a few ones at most), which means that the key management problem on that side is less difficult.

Since the AS will probably manage keys for many clients, the IDs need to be unique at least per AS. Therefore defining a namespace that is unique for a specific AS and prefixing the key ID with that namespace should work towards solving that problem.

You seem to have experience with specific issues in that matter, could you describe those issues in more detail?

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.

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.

The solution should work with both approaches. The client is expected to present credentials to the AS when requesting a token. These credentials can then be resolved to an identity, or a role, or some security attributes of the client. The AS is then expected to make an authorization decision based on the credentials and the existing authorization policies.

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.

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):

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.

OSCOAP and OSCON are based on COSE, which in turn is based on JOSE (JWE/JWS).  JOSE and COSE have some key provisioning functionality

6. If COAP option max length is 256 bits, how can a signature mechanism
   that requires that many bits be used?

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

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 30 Oct 2015 20:21:59 +0000

Hi Carsten, 

Thanks for the clarification. I think I picked up on the following
statement and then mixed up my bits and bytes:)

"5.2 Authorization Information Resource at the Resource Server
A consequence of allowing the use of CoAP as web transfer protocol is that
we cannot rely on HTTP specific mechanisms, such as transferring
information elements in HTTP headers since those are not necessarily
gracefully mapped to CoAP.  In case the access token is larger then 255
bytes it should not be sent as a CoAP option.”

Yes, as you say, we do want to reduce the size of the messages or probably
the frequency with which large messages are sent, e.g. By increasing the
life time of the OAUTH token. Now,  the questions are
1) whether we want to put the token or any type of signature inside an
option, given that COAP block protocol (not sure of the details) cannot
split the option as you say?
2) if we don’t want to take up so much message BW on a signature, what
integrity protection/ authentication mechanisms are we suggesting? From
what I understand with 256 bits EC keys, the ECDSA sig is 512+ bits. Are
folks suggesting MACs?

Reading COAP RFC 7252, section 5.4, I don’t see any option that sounds
like one that would carry an OAUTH token or a signature. Also my 10 min
investigation shows (section 3.1 option format) that the option length is
only 4 bits and after the reserved values, only allow for 1-12 bytes. Is
there some other clause that I missed? The option length extended maybe?

Regards,
Madjid Nakhjiri
麦志得 

>remaining message size is rather significant, but mostly not prohibitive.

************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 30 Oct 2015 21:05:29 +0000

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.
The problems are several:
a) devices may or may not have been personalized in the factory with
global key/ ID and product managers are still struggling whether the cost
is worth it, especially given some of the privacy/ user tracking issues (I
am thinking out loud here). So lots of tricks are being played for that
and the following reason.
B) the IOT device and the provisioning device (your AS) are completely
unknown to each other, so the problem of initial introduction and trust
bootstrapping is very real and prevalent. Even PKI may not help in case
the roots are not mutually trusted. This means in-band authentication is
not possible w/o trust bootstrapping. To make the matter worse, the
devices are headless, meaning that there is no screen or key board to type
something or read something.
I am not sure if these are the type of problems that IETF deals with right
now. I am just making a slow entry into IETF space now:)

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. 

Let me answer other questions inline

Regards,
Madjid Nakhjiri
麦志得 

>that clients and AS can use to reference keys.

Madjid>>From what I recall from looking at OAUTH a year or two back was
that they distinguish between confidential and public clients, depending
on their ability to perform “proper authentication” and keep their
credentials secret. This would also determine the type of grant that the
client gets.  I don’t think OAUTH spec deals with how the client
credentials gets provisioned into the clients and as a results, some
developers have simply hardcode the secret into the client code and on the
server side. This would not even possible in the world of IOT because the
device acting as client, the device acting as AS in the system are not
from the same vendor and don’t know each other from the past. Furthermore,
currently there is no “globalization mechanism” for defining Ids.
>that ACE will work on that issue.

Madjid>>fair enough. Is there any other place in IETF that deals with it?

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

>authorization decision based on the credentials and the existing

Madjid>>sounds good. I am glad both identity and role are being supported.

>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.
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?

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 30 Oct 2015 21:22:11 +0000

Thanks Erik.

I will throw these over on the to-read pile:)

Regards,
Madjid Nakhjiri
麦志得

From: Erik Wahlström neXus <[email-masked]<mailto:[email-masked]>>
Date: Thu, 29 Oct 2015 21:51:32 +0000
To: Ludwig Seitz <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] comments on draft-seitz-ace-oauth-authz-00

/ Erik

Hello Madjid,

/Ludwig

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

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________ Ace mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/ace

---

From: Göran Selander <[email-masked]>
Date: Sat, 31 Oct 2015 07:15:55 +0000

Hi Madjid,

Thanks for good comments, inline.

On 2015-10-30 21:21, "Madjid Nakhjiri" <[email-masked]>
wrote:

>like one that would carry an OAUTH token or a signature.

As you probably noted, the default case according to the draft is that the
client POSTs the access token to /authz-info at the resource server, i.e.
that the access token is sent in payload is thus not restricted in size
and can contain signature, MAC, or truncated MAC as appropriate for the
use case. In Appendix B we list some potential optimizations including a
new CoAP option intended to carry a reference token, which is then used by
the resource server in introspection to look up relevant authorization
information. If the access token is small such a CoAP option could in
principle be used without introspection but the exact size conditions is
TBD. My best guess is that a token containing essentially an identifier of
a role/capability list + a truncated MAC should fit into such a CoAP
option and thus enable the token to be carried within the resource request.

I don’t know if this answered any of your questions.

Göran

>Also my 10 min