On 2016-07-08 17:04, Renzo Navas wrote:
Hi ace wg, Hi Ludwig, Göran, et al.
~snip~Thank you Renzo for taking the time to do this review. Please find my comments inline.
Regards, Ludwig
---------------------------------------------------------------- Review of https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-02 --------------------------------------------------------------- 4. Protocol Interactions "The consent of the resource owner, for giving a client access to a protected resource, can be pre-configured authorization policies or dynamically at the time when the request is sent." "when the request is sent": The request we are talking is the Resource Request (Client already has the access token) or the token request? I believe is Resource Request. would it be good to explicit where this authz. policies are pre-configured (at the AS? were enforced before at the token request and are now embedded on the Access token; or at the RS?); and how the consent can be dynamically determined (will involve interaction with the Res Owner : RS to RO; RS to AS to RO ?). All this is out of scope of the draft, however I believe making explicit at least where the authz policies are pre-conf can be a good idea, just a suggestion. (My understanding is that they are at the AS; and were enforced at the token request; if introspection is used, can be enforced again at the resource request).
Sorry this is a case of bad word-choice by me. The idea is of course that the AS determines the consent of the RO at the time of the access token request (i.e. C -> AS). This can be either done by asking the RO or by using authorization policies defined by the RO previously at the AS. I'm adding an issue about this.
4. Messages Flows description: A-F: Would it be too redundant to state which security properties needs each messages, or it will be clearer? (A,B,D,E,F encrypted+integrity protected. C does not) This is just a question/suggestion; each message sec. requ. are stated in other parts of the draft (early on section 4, and on section 5 and 6...).
This could depend on the profiles, e.g. message B could need to be encrypted (if a symmetric PoP key is transferred) or just integrity protected (if a asymmetric PoP key is used). Therefore I'd rather not make these kind of statements here.
5. Framework Proof-of-Possession FROM " i.e. that the authenticated token holder is bound to the token." to Something like " i.e. that the token holder can prove being a holder of the key bound to the token"
Sounds good.
5. Framework "In OAuth 2.0 the communication with the Token and the Introspection resources at the AS (...) This framework RECOMMENDS to use CoAP instead and RECOMMENDS the use of the following alternative instead of Uri-query parameters: The sender (client or RS) encodes the parameters of its request as a CBOR map and submits that map as the payload of the POST request. The Content-format MUST be "application/cbor" in that case." If we use plain cbor on top of coap this means we are using dtls to protect the messages. If we are protecting the messages with cose, should we not use the Content-Format: "application/cose;cose-type=cose-encrypt" ? All the examples of the doc use appplication/cbor; however, can be useful to mention somewhere (here?) that if cose is used the content format is "application/cose"?
Correct, if we add other security wrappers around the data we may need to change the Content-format. I'll add an issue about this.
----------------------
6. The 'Token' Resource
"Communication between the client and the token resource at the AS
MUST be integrity protected and encrypted. Furthermore AS and client
MUST perform mutual authentication. Profiles of this framework are
expected to specify how authentication and communication security is
implemented."
Is it worthy (.. is it accurate?) to express that the Token Request,
from C to AS might not be source-authenticated, and the AS -in that
case- can authenticate the request ("a posteriori") with the
client_id/client_secret?
The buzz in my head came because authentication of the client can be
done at dtls/cose level (that, for me, its not a must), and also with
the client credentials inside the request.
I think that the description on the text is generic enough so any
interpretation of how to authenticate the C towards AS, is OK.
In any case I send to you this (confusing) thoughts I had when I first
read this sentence. Authentication can be done at communication level
with the PSK C-AS , and also with the client_secret (maybe this is an
"application authentication"...).
You are right, we should clarify these options ... creating an issue
6. The 'Token' Resource "The figures of this section uses CBOR diagnostic notation without the integer abbreviations for the parameters or their values for better readability." (already did this comment) is worth mentioning that if cose is used, the coap messages content-type are application/cose, and we show the cbor plaintext payload?
Yes that was the intention of these examples. I'll check if that needs clarification.
------------------- 6.1. Client-to-AS Request Figure 3: Example request for an access token bound to an asymmetric key. "grant_type" : "token" I have not found the definition of grant_type "token" , should not be "client_credentials"? ( https://tools.ietf.org/html/rfc6749#section-4.4.2 )
Good catch! I think that was just an error.
------------
6.2. AS-to-Client Response
Figure 5: Example AS response with an access token bound to a symmetric key.
"{ "access_token" : b64'SlAV32hkKG ...
(...),
"token_type" : "pop",
"alg" : "HS256",
"cnf" : {
"COSE_Key" : { ...."
how does the "alg" field of the token response relates to the
"key_alg" from the COSE_Key object if present, they must match , or
cose_key alg must be a super-set of this "alg"?
In 6.4.2 this "alg" is defined, Now that I read the passage
attentively, this "alg" field in the token response is only used for
the initial PoP; then the key can be used with other algorithms (e.g.
to encrypt with aes-ccm). OK.
I left this comment to show the confusion that produced the "alg"
field at two different levels, maybe its worthy to briefly tell the
difference/purpose of each one in contrast to each other.
------------
The intention is of course that 'alg' is used to identify the initial PoP procedure, this may include generating further keys for communication security. Obviously the key_alg parameter, if present, should identify the same algorithm as the alg parameter.
I'll add an issue to clarify this.
6.4.4. Confirmation "COSE_Encrypted In this case the 'cnf' parameter contains an encrypted symmetriic key destined for the client." (typo "symmetriic").
Noted.
Is it needed to encrypt the symmetric key inside cnf?
If the channel is not secure this would be necessary. Otherwise you can just use a COSE_Key inside 'cnf'
Was not assumed that the communication between AS and Client was already protected (the whole response was integrity protected and encrypted). Or it was a general statement, and this is a particular case? In any case, fields outside cnf should be at least integrity protected.
It might be the case that this is not really needed. I'll go through the use cases and check. This comes from the fact that we copied the properties of the 'cnf' parameter form RFC7800, which includes an encrypted key.
I think that depends on the specific contents of the message, so I'm not sure if it can be said generally for each message.GENERAL OBSERVATION (already did on section 4): Can be a good idea to specify for each message which kind of security properties (confidentiality, integrity/data authentication)' we need and at what level/layer (e.g: transport layer/application layer, Cose_key field needs confidentiality but the rest only integrity, etc.)?
----------- 7. The 'Introspect' Resource " Finally the AS SHOULD to verify that the RS" remove/"to" ? ------------
Noted
7.4. Client Token Personally I believe this is a very relevant use case. This "client token" solution is elegant, and easy to understand on the context on the rest of the framework. ------------ 8.2. Token Expiration "RS verifies these by comparing them to values from its internal clock as defined in [RFC7519]. In this case the RS must have a real time chip (RTC) or some other ..." Shall it say "real time clock (RTC)"? Its worthy to be more clear and say that the internal clock should reflect the current date/time, or at least be synchronized with the issuer-of-the-token's clock (the AS)?
I'll clarify this.
---------------------- Appendix C. Deployment Examples Comment: I found it VERY useful to see the real exchange of messages. C.1. Local Token Validation " The token includes the claim "aif" with the authorized access that an owner of the temperature device can enjoy. The 'aif' claim, issued by the AS, informs the RS that the owner of the token, that can prove the possession of a key is authorized to" The first sentence should not say: ".. that an owner of the of the token, that can prove the possession of a key can enjoy" instead of the "owner of the temperature device" ?
Sorry all the examples in the appendices are not up to date, we intended to remove the 'aif' claim from this document for the time being and missed this section.
C.1. Local Token Validation About "AIF" claim should not reference https://tools.ietf.org/html/draft-bormann-core-ace-aif-03 somewhere? "aif" claim is only mentioned on appendix C, what happened on the rest of the document? (is not a valid claim?) In cbor web token (https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-00#appendix-A.3 ) , the only reference of aif is on Appendix 3! shall we give more visibility for the aif claim on the main body of the doc?
See comment above.
--------------------------------------------
C.2. Introspection Aided Token Validation
"Figure 23: Request and Response Payload for C offline"
"COSE_Key" : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
"kty" : "oct",
"alg" : "HS256",
"
* Should not be: "kty": "Symmetric " ?
I'll check that.
* "alg", supossedly this is key_alg that specifies "Key usage restriction to this algorithm". "HS256", I found a reference on json web token, and says "indicates that this token is signed using HMAC-SHA256." Should not be put on "alg" the algorithm that will be used on the DTLS-PSK performed later? e.g.: "AES-CCM-16-64-128"?
This is actually not quite clear in the COSE draft. Table 3 suggests the parameter should be called 'alg' not 'key_alg'. I'll ask for clarification by Jim Schaad.
I think this example needs to be updated as well, it seems broken.
------------------------------ "E: The AS provides the introspection response containing (...). (...) allows the RS to verify the client's proof of possession in step F. After receiving message E, the RS responds to the client's POST in step C with Code 2.01 Created." See "Figure 24: Token Introspection for C offline" "step C with Code 2.01 Created", Is this not the "Step F"?
Yes this figure is not aligned with the steps in figure 1. I'll fix that.
------------- Both comments coming from "Figure 25: Request and Response Payload for Introspection:" "Request-Payload: ... "client_id" : "FrontDoor", "client_secret" : "ytrewq" " This is introspection request from RS to AS. How did the RS got the client_id and the client_secret? (previous, message from C to RS is not protected)
Good catch, all these examples in the appendices need to be looked over I think.
"Response-Payload:
...
"cnf" : {
"kid" : b64'...'}
"
Should not "cnf" need to have the whole "COSE_Key" (including "k")?
On the text it was not assumed that RS and C already shared a Key (if
they did, at some point after original C-AS request, AS must have
provisioned it to RS -this can be assumed-).
In the general case AS will have to transport the key to RS on the
introspection response I think
You are right there as well. -- 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
