Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
On 13/12/2018 15:42, Stefanie Gerdes wrote: Hi Ludwig, On 12/12/2018 10:47 AM, Ludwig Seitz wrote: The value of checking the iss field is indeed limited, but if present I feel it MUST be checked. The text does say that the RS must check the integrity of the token (see 5.8.1.1.) "Since the cryptographic wrapper of the token (e.g. a COSE message) could include encryption, it needs to be verified first, based on shared cryptographic material with recognized AS." This implies that the RS must check that the AS is recognized, I will rephrase this to clarify that "recognized" means that the AS is authorized to issue tokens for the RS. I cannot find the term "integrity" in section 5.8.1.1. Encryption is not the same as integrity protection. "Cryptograpic wrapper" can include integrity protection. The reason encryption is specifically mentioned here is that you have to process the crypto wrapper first, before doing any checks on the claims, since they could be encrypted. I have tried to rephrase this in the editor's version to clarify. (Side note: Basically you would want to do it the other way around, since it is much less resource consuming to verify the claims compared to verifying the crypto wrapper. Thus if you could discard a token due to some issue with the claims without having to check the crypto you would save some energy and time. Sadly since the token could be encrypted you cannot do it in that order) Also, providing a "cryptographic wrapper" for the token seems to be optional, which means that RS does not necessarily check the authenticity of the token. The RS must check that the token stems from an authorized AS, otherwise anyone can issue a token to RS. In OAuth you have different types of tokens, CWTs and JWTs typically have a cryptographic wrapper (but see section 6 of RFC 7519), but a token could just as well only be a random identifier, that the RS has to perform introspection on to learn the associated claims. Such a "reference token" would not have a cryptographic wrapper. BTW, "shared cryptographic material with recognized AS" implies that only symmetric solutions can be used between RS and AS. Is that what you intend here? Not really, "shared cryptographic material" could be public keys that the AS and RS have shared with each other. The current text to the iss field implies that this field somehow helps RS to determine the origin of the token, but this is not the case. Anyone can write an authorized issuer into an issuer field. Authenticity can only be achieved with cryptographic measures. I agree that the iss claim is not really useful to authenticate the issuer, however if it is present in the token the RS should process it. The text I wrote was not intended to imply that it helps with anything: "The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS. If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.01 (Unauthorized)." This text is just instructions on how to process the claim. The authenticity of the issuer would either be verified by the the cryptographic wrapper or by introspection. (Side note: If an RS gets a "reference token" it would implicitly verify the authenticity of the issuer by doing introspection at the AS that is authorized to issue tokens for it). Instead of demanding that the exp field is checked the document should demand that the RS somehow validates that the token is not expired. Checking the exp field may be one example. The document demands that exp is checked _if present_. I don't like to normatively require something that is not concrete such as "somehow validate that the token is not expired". If we define other ways than exp and exi, then normative requirements should be placed in the documents that define those. So you say that the exp field is optional. And the exi field is optional. If they are missing, the RS does not check if the token is still valid and may use outdated tokens. No if both fields are missing, the token is valid indefinitely, until explicitly revoked. For the security of the solution it is required that the RS checks if the token is still valid. You should point out this requirement to achieve a secure solution. Yes but the RS can only do this based on the claims associated to the token. Certain profiles may require certain sets of claims to be in the token (e.g. aud, scope, exp/exi), but putting such requirements in the framework would be quite a big divergence from OAuth. Well you have several cases of keying material here: a.) A symmetric pop-key bound to one or more tokens. That will only be valid as long as there is a valid token. b.) An asymmetric key belonging to either client of RS, which may be bound to a token, or used to authenticate (e.g. in a DTLS-RPK handshake). Those are valid independently of the ACE framework and need to be managed, updated and
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
Hi Ludwig, On 12/12/2018 10:47 AM, Ludwig Seitz wrote: > The value of checking the iss field is indeed limited, but if present I > feel it MUST be checked. > > The text does say that the RS must check the integrity of the token (see > 5.8.1.1.) > > "Since the cryptographic wrapper of the token (e.g. a COSE message) > could include encryption, it needs to be verified first, based on shared > cryptographic material with recognized AS." > > This implies that the RS must check that the AS is recognized, I will > rephrase this to clarify that "recognized" means that the AS is > authorized to issue tokens for the RS. I cannot find the term "integrity" in section 5.8.1.1. Encryption is not the same as integrity protection. Also, providing a "cryptographic wrapper" for the token seems to be optional, which means that RS does not necessarily check the authenticity of the token. The RS must check that the token stems from an authorized AS, otherwise anyone can issue a token to RS. BTW, "shared cryptographic material with recognized AS" implies that only symmetric solutions can be used between RS and AS. Is that what you intend here? The current text to the iss field implies that this field somehow helps RS to determine the origin of the token, but this is not the case. Anyone can write an authorized issuer into an issuer field. Authenticity can only be achieved with cryptographic measures. > >>> Instead of demanding that the exp field is checked the document should >>> demand that the RS somehow validates that the token is not expired. >> Checking >>> the exp field may be one example. > The document demands that exp is checked _if present_. > I don't like to normatively require something that is not concrete such > as "somehow validate that the token is not expired". If we define other > ways than exp and exi, then normative requirements should be placed in > the documents that define those. So you say that the exp field is optional. And the exi field is optional. If they are missing, the RS does not check if the token is still valid and may use outdated tokens. For the security of the solution it is required that the RS checks if the token is still valid. You should point out this requirement to achieve a secure solution. > > Well you have several cases of keying material here: > > a.) A symmetric pop-key bound to one or more tokens. That will only be > valid as long as there is a valid token. > > b.) An asymmetric key belonging to either client of RS, which may be > bound to a token, or used to authenticate (e.g. in a DTLS-RPK > handshake). Those are valid independently of the ACE framework and need > to be managed, updated and expired by some other mechanisms. > > c.) A symmetric key shared between C-AS or RS-AS for authentication > purposes. ACE has no mechanisms for managing and updating this kind of > keys. Starting to look into this looks lite a rat-hole to me. I am currently only referring to the keying material that AS provides to C, i.e., the symmetric key shared between C and RS or, if asymmetric keys are used, RS's RPK. Since it is clear to you that symmetric keys are only valid as long as the token, you should point that out in the document. C then has at least some clue how long the token is valid. Which is better than nothing. In the RPK case, the AS may be the one that provides C with RS's RPK. RPKs do not contain semantic information. Therefore, C must be able assume that the RPK is valid as long as the access token. As I said, the framework must also state that the client must check if its keying material is still valid each time before it sends a request to the RS. Otherwise the confidentiality of the request data may be breached. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
On 12/12/2018 10:27, Stefanie Gerdes wrote: Hi Jim, thank you for your quick response. On 12/11/2018 09:38 PM, Jim Schaad wrote: C may receive keying material for the communication with RS from AS. Unfortunately, the AS does not inform C how long the keying material is valid. C therefore may use outdated keying material for the communication. C cannot rely on RS to reject messages that were sent with outdated keying material because 1. the information in the request sent by C may be confidential and is then compromised and 2. C cannot be sure that it is actually communicating with the intended RS if the keying material is no longer valid. Would you feel that this would be eased by requiring the expires_in field to be required as part of the response? It is the expiration of the token, but I have never understood the difference between the expiration of the token and the expiration of keying material myself. Keying material never expires, you just cannot use it without a valid token. As long as it is clear that the expires_in field describes the time until the keying material expires, this is at least better than nothing, although it leaves the problem that the client does not know when the token was created and how much time has already passed since then. The ACE framework should also point out that a client must check if its keying material for RS is still valid before it makes a request. BTW, I don't think keying material should be valid forever, especially if there is no useful revocation mechanism. Note that expires_in (exi) is currently defined as "expires in x seconds from the time at which the RS first saw the token". I am aware that this is quite weak since malicious clients can hoard tokens that would be valid indefinitely. I do not currently see any other means of expiration when the RS has no connectivity to the AS and no synchronized clock. I would be open for suggestions if you have better ideas. I did not find any indication how the client knows how to choose the correct req_aud for RS. The document must point out that C may communicate with the wrong RS unless C and AS have a common understanding how RS is identified. Scope is also something that the client does not know how to build. In the worst case, a wrong scope can only prevent a client from accessing a certain resource. Even if the client does not specify any scope, the AS can still grant it permissions. If they are broad enough, they will likely cover the resource that C wants to access. A wrong req_aud however may cause the client to communicate with the wrong RS. Even worse, C will not be able to notice that it communicates with the wrong RS. This is a serious security risk. > Currently, the ACE framework does not even acknowledge that such a risk exists. We do acknowledge that, in the security considerations of draft-ietf-ace-oauth-params where req_aud is defined. I'll add additional clarification to that text though, since it currently only talks about the needing to RS know which audiences it recognizes. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
On 11/12/2018 21:38, Jim Schaad wrote: -Original Message- From: Ace On Behalf Of Stefanie Gerdes Sent: Tuesday, December 11, 2018 4:11 AM To: Ludwig Seitz ; ace@ietf.org Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz- 17.txt and draft-ietf-ace-oauth-params-01.txt Hi, I looked through the document again. Many issues have been fixed, but I still have some comments: I still think that Section 5.8.1, in particular 5.8.1.1 should point out that RS must check the integrity of the token und validate that it stems from an authorized AS. Checking the iss field does not help in this case and I don't see much value in this check; cryptographic assurance such as AS' signature or MAC of the token is required to ascertain the authenticity, and in this case the issuer, of the token. I would agree with this. I have never been sure why the 'iss' field is going to be useful. The only place that I can see this would be an AS which is using one key but two identities. I would argue that this is a situation that is prone to configuration errors and incorrect security. The value of checking the iss field is indeed limited, but if present I feel it MUST be checked. The text does say that the RS must check the integrity of the token (see 5.8.1.1.) "Since the cryptographic wrapper of the token (e.g. a COSE message) could include encryption, it needs to be verified first, based on shared cryptographic material with recognized AS." This implies that the RS must check that the AS is recognized, I will rephrase this to clarify that "recognized" means that the AS is authorized to issue tokens for the RS. 5.8.1. exiting -> existing Fixed. Section 5.8.1. states that RS must check that the expiration time given in the exp field is in the future. This is difficult if the RS is not time synchronized. Indeed, but in those cases one wouldn't use the exp claim in the first place. I will add some text to the assumptions on AS knowledge about C and RS to the effect that the AS should know if the RS can manage synchronized time. Option 3 in section 5.8.3 seems to suggest that this field is not always required. Indeed no claim is specifically required in the framework. Instead of demanding that the exp field is checked the document should demand that the RS somehow validates that the token is not expired. Checking the exp field may be one example. The document demands that exp is checked _if present_. I don't like to normatively require something that is not concrete such as "somehow validate that the token is not expired". If we define other ways than exp and exi, then normative requirements should be placed in the documents that define those. C may receive keying material for the communication with RS from AS. Unfortunately, the AS does not inform C how long the keying material is valid. C therefore may use outdated keying material for the communication. C cannot rely on RS to reject messages that were sent with outdated keying material because 1. the information in the request sent by C may be confidential and is then compromised and 2. C cannot be sure that it is actually communicating with the intended RS if the keying material is no longer valid. Would you feel that this would be eased by requiring the expires_in field to be required as part of the response? It is the expiration of the token, but I have never understood the difference between the expiration of the token and the expiration of keying material myself. Keying material never expires, you just cannot use it without a valid token. Well you have several cases of keying material here: a.) A symmetric pop-key bound to one or more tokens. That will only be valid as long as there is a valid token. b.) An asymmetric key belonging to either client of RS, which may be bound to a token, or used to authenticate (e.g. in a DTLS-RPK handshake). Those are valid independently of the ACE framework and need to be managed, updated and expired by some other mechanisms. c.) A symmetric key shared between C-AS or RS-AS for authentication purposes. ACE has no mechanisms for managing and updating this kind of keys. Starting to look into this looks lite a rat-hole to me. Does any of you feel we should document this in the framework? I'm currently leaning towards no, but could be convinced otherwise. I did not find any indication how the client knows how to choose the correct req_aud for RS. The document must point out that C may communicate with the wrong RS unless C and AS have a common understanding how RS is identified. Scope is also something that the client does not know how to build. Learning the correct req_aud and scope is out of scope (no pun intended) for ACE. This would either be part of the configuration of a client, or a client could look it up in some resource directory. I'll add the note about needing to
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
Hi Jim, thank you for your quick response. On 12/11/2018 09:38 PM, Jim Schaad wrote: >> >> C may receive keying material for the communication with RS from AS. >> Unfortunately, the AS does not inform C how long the keying material is > valid. C >> therefore may use outdated keying material for the communication. C cannot >> rely on RS to reject messages that were sent with outdated keying material >> because 1. the information in the request sent by C may be confidential > and is >> then compromised and 2. C cannot be sure that it is actually communicating >> with the intended RS if the keying material is no longer valid. > > Would you feel that this would be eased by requiring the expires_in field to > be required as part of the response? It is the expiration of the token, but > I have never understood the difference between the expiration of the token > and the expiration of keying material myself. Keying material never > expires, you just cannot use it without a valid token. As long as it is clear that the expires_in field describes the time until the keying material expires, this is at least better than nothing, although it leaves the problem that the client does not know when the token was created and how much time has already passed since then. The ACE framework should also point out that a client must check if its keying material for RS is still valid before it makes a request. BTW, I don't think keying material should be valid forever, especially if there is no useful revocation mechanism. > >> >> I did not find any indication how the client knows how to choose the > correct >> req_aud for RS. The document must point out that C may communicate with >> the wrong RS unless C and AS have a common understanding how RS is >> identified. > > Scope is also something that the client does not know how to build. In the worst case, a wrong scope can only prevent a client from accessing a certain resource. Even if the client does not specify any scope, the AS can still grant it permissions. If they are broad enough, they will likely cover the resource that C wants to access. A wrong req_aud however may cause the client to communicate with the wrong RS. Even worse, C will not be able to notice that it communicates with the wrong RS. This is a serious security risk. Currently, the ACE framework does not even acknowledge that such a risk exists. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
Hi, I looked through the document again. Many issues have been fixed, but I still have some comments: I still think that Section 5.8.1, in particular 5.8.1.1 should point out that RS must check the integrity of the token und validate that it stems from an authorized AS. Checking the iss field does not help in this case and I don't see much value in this check; cryptographic assurance such as AS' signature or MAC of the token is required to ascertain the authenticity, and in this case the issuer, of the token. 5.8.1. exiting -> existing Section 5.8.1. states that RS must check that the expiration time given in the exp field is in the future. This is difficult if the RS is not time synchronized. Option 3 in section 5.8.3 seems to suggest that this field is not always required. Instead of demanding that the exp field is checked the document should demand that the RS somehow validates that the token is not expired. Checking the exp field may be one example. C may receive keying material for the communication with RS from AS. Unfortunately, the AS does not inform C how long the keying material is valid. C therefore may use outdated keying material for the communication. C cannot rely on RS to reject messages that were sent with outdated keying material because 1. the information in the request sent by C may be confidential and is then compromised and 2. C cannot be sure that it is actually communicating with the intended RS if the keying material is no longer valid. I did not find any indication how the client knows how to choose the correct req_aud for RS. The document must point out that C may communicate with the wrong RS unless C and AS have a common understanding how RS is identified. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
Ludwig, It looks good. A couple of additional things that have occurred to me. (Always a problem when on reads drafts again and again.) 1. I don't really have a problem with figure 6, but I don't know if we want to more correctly reflect what an OSCORE message would look like in this location. This would basically be a re-write of the entire example structure to reflect that you have an outer and an inner CoAP message. It might be confusing for people who are not fully immersed in the OSCORE world. 2. I have no idea of where this would go and it is perhaps something that the OAuth people need to think about as well. If an AS receives a request which has message level security (OSCORE/CWT/JWT) over a session level security connection (TLS/DTLS/IPSEC) are there any rules/suggestions about which keys should be used for evaluating the resulting request. While I assume that message security wins and the session security is ignored, I have not seen this anyplace. 3. In section 5.8.1 - It says that for a CWT access token that the application/cwt content type MUST be used. There are two possible issues with this. 1) How does the client know what the type of the token is. It could be a CWT, an introspection token, or something else entirely. 2) Is it an error if a CWT token is received and the content type is not present? Jim > -Original Message- > From: Ace On Behalf Of Ludwig Seitz > Sent: Monday, November 26, 2018 1:27 AM > To: ace@ietf.org > Subject: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz- > 17.txt and draft-ietf-ace-oauth-params-01.txt > > Hello ACE, > > I have just submitted new versions for draft-ietf-ace-oauth-authz and draft-ietf- > ace-oauth-params addressing the WGLC review comments and the discussions > from the IETF 103 meeting. > > I would encourage the reviewers to check if they feel that I have sufficiently > addressed their comments. > > > Regards, > > Ludwig > > Forwarded Message > > A new version of I-D, draft-ietf-ace-oauth-authz-17.txt > has been successfully submitted by Ludwig Seitz and posted to the > IETF repository. > > Name: draft-ietf-ace-oauth-authz > Revision: 17 > Title:Authentication and Authorization for Constrained Environments > (ACE) using the OAuth 2.0 Framework (ACE-OAuth) > Document date:2018-11-26 > Group:ace > Pages:74 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-17.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-17 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-17 > > Abstract: > This specification defines a framework for authentication and > authorization in Internet of Things (IoT) environments called ACE- > OAuth. The framework is based on a set of building blocks including > OAuth 2.0 and CoAP, thus making a well-known and widely used > authorization solution suitable for IoT devices. Existing > specifications are used where possible, but where the constraints of > IoT devices require it, extensions are added and profiles are > defined. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > Forwarded Message > > A new version of I-D, draft-ietf-ace-oauth-params-01.txt > has been successfully submitted by Ludwig Seitz and posted to the > IETF repository. > > Name: draft-ietf-ace-oauth-params > Revision: 01 > Title:Additional OAuth Parameters for Authorization in Constrained > Environments (ACE) > Document date:2018-11-26 > Group:ace > Pages:14 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ > Htmlized: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-01 > > Abstract: > This specification defines new parameters for the OAuth 2.0 token and > introspection endpoints when used with framework for authentication > and authorization for constrained environments (ACE). These are used > to express the desired audience of a requested access token, the > desired proof-of-possession key, the proof-of-possession key that the > AS has selected, and the key the RS should use to authenticate to the > client. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at
