Re: [Ace] est-coaps clarification on /att and /crts
Max Pritikin (pritikin) wrote: > Jim Schaad wrote: > jim> Clarification requested - exactly what element is the Registrar? mcr> It's an EST RFC7030 term, but essentially it's the server that mcr> connects to (or is) the CA. max> The Registrar terminology is from the Anima working group and is closely max> analogous to the “Registration Authority” we know and love from the PKI max> space. Oh, right. I forgot that Registration Authority (RA) is not the same word as "Registrar". I wonder if we should have aligned that more, or aligned it less. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Anima] est-coaps clarification on /att and /crts
Hannes Tschofenig wrote: > > We want all our clients to be authenticated by DTLS before they start > > loading up our RF network. > > I'm not suggesting that the DTLS be skipped, I'm suggesting that the > > client certificate presented might be meaningless to the EST server. > I am curious what security model you have in mind? If you don't do client > authentication then you are essentially issuing certificates to an > anonymous entity. This feels like a very bad idea, particularly since the > CA is supposed to assert the identifier of the client via the certificate. Clients which are not **yet** authenticatable. The client shows up, does a DTLS connection. We let the DTLS connection succeed, because we want to record the particulars of the client, so we can ask a human. Much like happens when you ssh to a new host: it stops to ask if you you agree with the key. You don't know, so you hit ^C. So, that's all. We don't intend to issue certificates... yet. I'm also asking if there is some use case where the client might legitimate need the list of trust anchors (/cacerts request) in order so that it can...? (I couldn't think of a use case) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Panos Kampanakis (pkampana) wrote: > Gotcha, so you are describing a provisional DTLS connection at the server. I'm thinking about a Registrar that might be serving both provisional connections and ones that are just renewing LDevIDs, and maybe ones that also serve selected factory installed IDevIDs (a use case which est-coaps caters directly to). > Currently we say that clients need to be authenticated in a DTLS connection > before an EST-coaps request. Do you want to make it more explicit to say > that even though EST allowed for it, EST-coaps does not allow > unauthenticated /crt and /att? We can certainly add that. I'd like to add this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
> -Original Message- > From: Ace On Behalf Of Hannes Tschofenig > Sent: Wednesday, December 12, 2018 8:01 AM > To: Panos Kampanakis (pkampana) ; Michael > Richardson ; ace@ietf.org; an...@ietf.org > Cc: Peter van der Stok ; Max Pritikin (pritikin) > > Subject: Re: [Ace] est-coaps clarification on /att and /crts > > Hi Panos, Hi Michael, > > > We want all our clients to be authenticated by DTLS before they start loading > up our RF network. > > I'm not suggesting that the DTLS be skipped, I'm suggesting that the client > certificate presented might be meaningless to the EST server. > > I am curious what security model you have in mind? If you don't do client > authentication then you are essentially issuing certificates to an anonymous > entity. This feels like a very bad idea, particularly since the CA is supposed to > assert the identifier of the client via the certificate. > > What am I missing here? Hannes, What you are missing is that the question is not about issuing the certificate. That is going to require client authentication. What is being looked at is getting the list of trust anchors or the template for a certificate request based on an anonymous client. Jim > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Overwriting Tokens
> -Original Message- > From: Ace On Behalf Of Stefanie Gerdes > Sent: Wednesday, December 12, 2018 2:17 AM > To: ace@ietf.org > Subject: Re: [Ace] Overwriting Tokens > > Hi Ludwig, > > On 12/12/2018 11:05 AM, Ludwig Seitz wrote: > > On 12/12/2018 10:33, Stefanie Gerdes wrote: > >> Hi again, > >> > >> I have one additional comment to ace-oauth-17: > >> > >> Section 5.8.1 recommends that RS stores only one token per key and > >> that existing tokens are overwritten by new tokens. I wonder how the > >> RS knows which token is the most recent. I don't think the expiration > >> time helps in this case because it should be possible for the AS to > >> provide a token that expires earlier than the previous token. > >> > >> > >> Viele Grüße > >> Steffi > >> > > > > "Recent" here is meant as "most recently received". That is something > > the RS definitely can track. > > The token most recently received by RS is not necessarily the newest. > A client may (accidentally or not) send the older token later than the newer > token. And as you stated above, the older token may have a longer expiration than the newer because of a different set of permissions. I think that having the RS use the most recently received token is probably the best strategy for an RS that I only going to keep one token. The client will know which token is tagged to what original request if it is keeping more than one token itself. If it is must immediately posting tokens as it goes along, then the AS could provide an older, but still valid, token on the next request. Jim > > Viele Grüße > Steffi > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Hi Hannes, Michael was only asking if allowing any anonymous entity to get the cacerts (trusted root cert list) is worth it. RFC7030 allows for this. Of course an enrollment would still require authentication/authorization. I was making the case that it is not worth to even allow anonymous get cacerts. Panos -Original Message- From: Hannes Tschofenig Sent: Wednesday, December 12, 2018 11:01 AM To: Panos Kampanakis (pkampana) ; Michael Richardson ; ace@ietf.org; an...@ietf.org Cc: Peter van der Stok ; Max Pritikin (pritikin) Subject: RE: est-coaps clarification on /att and /crts Hi Panos, Hi Michael, > We want all our clients to be authenticated by DTLS before they start loading > up our RF network. > I'm not suggesting that the DTLS be skipped, I'm suggesting that the client > certificate presented might be meaningless to the EST server. I am curious what security model you have in mind? If you don't do client authentication then you are essentially issuing certificates to an anonymous entity. This feels like a very bad idea, particularly since the CA is supposed to assert the identifier of the client via the certificate. What am I missing here? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] est-coaps clarification on /att and /crts
Hi Panos, Hi Michael, > We want all our clients to be authenticated by DTLS before they start loading > up our RF network. > I'm not suggesting that the DTLS be skipped, I'm suggesting that the client > certificate presented might be meaningless to the EST server. I am curious what security model you have in mind? If you don't do client authentication then you are essentially issuing certificates to an anonymous entity. This feels like a very bad idea, particularly since the CA is supposed to assert the identifier of the client via the certificate. What am I missing here? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Overwriting Tokens
Hi Ludwig, On 12/12/2018 11:05 AM, Ludwig Seitz wrote: > On 12/12/2018 10:33, Stefanie Gerdes wrote: >> Hi again, >> >> I have one additional comment to ace-oauth-17: >> >> Section 5.8.1 recommends that RS stores only one token per key and that >> existing tokens are overwritten by new tokens. I wonder how the RS knows >> which token is the most recent. I don't think the expiration time helps >> in this case because it should be possible for the AS to >> provide a token that expires earlier than the previous token. >> >> >> Viele Grüße >> Steffi >> > > "Recent" here is meant as "most recently received". That is something > the RS definitely can track. The token most recently received by RS is not necessarily the newest. A client may (accidentally or not) send the older token later than the newer token. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Overwriting Tokens
On 12/12/2018 10:33, Stefanie Gerdes wrote: Hi again, I have one additional comment to ace-oauth-17: Section 5.8.1 recommends that RS stores only one token per key and that existing tokens are overwritten by new tokens. I wonder how the RS knows which token is the most recent. I don't think the expiration time helps in this case because it should be possible for the AS to provide a token that expires earlier than the previous token. Viele Grüße Steffi "Recent" here is meant as "most recently received". That is something the RS definitely can track. /Ludwig -- 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 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 have a common understanding about
[Ace] Overwriting Tokens
Hi again, I have one additional comment to ace-oauth-17: Section 5.8.1 recommends that RS stores only one token per key and that existing tokens are overwritten by new tokens. I wonder how the RS knows which token is the most recent. I don't think the expiration time helps in this case because it should be possible for the AS to provide a token that expires earlier than the previous token. 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 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
