Subject: Re: [Ace] draft-greevenbosch-core-authreq-00

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 15 Jan 2014 03:32:45 +0000

Hi Hannes,

Thank you for your comments, and sorry for my late response.

Please find my replies inline.

> Your first use case (Section 3.1; maybe also Section 3.8?) with the title “authorized and unauthorized devices” make an interesting distinction between the two types of devices. You basically draw the line based on whether the device passed certification testing (or not). During the protocol execution you seem to assume that the authentication credentials reveal whether a device passed certification testing or not. While this is clearly possible it is a rather unusual scenario. Is this something you have seen being used or envisioned somewhere or did you create this scenario yourself?

This is a basic security requirement. After all, it is often unwise to trust insecure implementations, and as such a certificate should only be provided to devices that are worthy of such trust, or at least a recipient should be able to judge from the certificate whom it is talking to, and if this is an acceptable party. Isn't that a reason for X.509 fields such as "Subject" and "Issuer"? I guess without proper verification any certificate would be usable to setup an encrypted connection.

> Many of the scenarios you outline deal with revocation (such as Section 3.3, 3.5, 3.6, 3.7). The scenarios described in Scenarios 3.2 and 3.4 raise the requirements for fine-grained access control. Was this intentional or did I misinterpret something?

Yes, there is a greater part dealing with revocation, also due to the legacy from an earlier document that focussed more on revocation. But indeed access control deserves proper attention, especially in the current scope of ACE. Hence sections 3.2 and 3.4, as well as 3.9.

> For the text in Section 3.9 you focus on a small subset of privacy threats, namely surveillance. Maybe you should refer explicitly to surveillance or extend the write-up to also include other privacy threats, see RFC 6973.

Thanks, RFC 6973 certainly is an interesting document. Indeed the use case in section 3.9 focuses mainly on man-in-the-middle attacks, i.e. surveillance (or tampering). Authentication also protects against "misattribution" (as described in RFC 6973 section 5.1.4), however at the same time this removes anonymity of related communications. Do you think of any specific information that should be added?

Thanks again for your feedback!

Best regards,
Bert

---
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: 13 December 2013 01:37
To: [email-masked]
Subject: [Ace] draft-greevenbosch-core-authreq-00

Dear Bert, 
 
Thanks for your document. I also ran into questions when I looked at your document. 
 
Your first use case (Section 3.1; maybe also Section 3.8?) with the title “authorized and unauthorized devices” make an interesting distinction between the two types of devices. You basically draw the line based on whether the device passed certification testing (or not). During the protocol execution you seem to assume that the authentication credentials reveal whether a device passed certification testing or not. While this is clearly possible it is a rather unusual scenario. Is this something you have seen being used or envisioned somewhere or did you create this scenario yourself? 
 
Many of the scenarios you outline deal with revocation (such as Section 3.3, 3.5, 3.6, 3.7). The scenarios described in Scenarios 3.2 and 3.4 raise the requirements for fine-grained access control. Was this intentional or did I misinterpret something? 
 
For the text in Section 3.9 you focus on a small subset of privacy threats, namely surveillance. Maybe you should refer explicitly to surveillance or extend the write-up to also include other privacy threats, see RFC 6973. 
 
Similarly to my comments regarding the other documents I am curious how you came up with these scenarios. It is fine if you came up with them yourself but it would be good to know. 
 
Ciao
Hannes

---

From: Bert Greevenbosch <[email-masked]>
Date: Thu, 16 Jan 2014 06:32:57 +0000

Hi Hannes,

> > Your first use case (Section 3.1; maybe also Section 3.8?) with the
> title “authorized and unauthorized devices” make an interesting
> distinction between the two types of devices. You basically draw the
> line based on whether the device passed certification testing (or not).
> During the protocol execution you seem to assume that the
> authentication credentials reveal whether a device passed certification
> testing or not. While this is clearly possible it is a rather unusual
> scenario. Is this something you have seen being used or envisioned
> somewhere or did you create this scenario yourself?
> 
> This is a basic security requirement. After all, it is often unwise to
> trust insecure implementations, and as such a certificate should only
> be provided to devices that are worthy of such trust, or at least a
> recipient should be able to judge from the certificate whom it is
> talking to, and if this is an acceptable party. Isn't that a reason for
> X.509 fields such as "Subject" and "Issuer"? I guess without proper
> verification any certificate would be usable to setup an encrypted
> connection.

Sorry, I thought your comment over again, and indeed I agree that may not be as trivial as I first understood.

What I described is how one can use the certificate to distinguish between acceptable/trustworthy and unacceptable/untrustworthy parties. But indeed, the device may also use other mechanisms to distinguish these, e.g. some kind of vendor query: there could be an URI towards which a GET would deliver vendor information. As long as there is no lying involved, this would also be a useful filter for the devices.

The check would be enough to filter out the genuine but unacceptable/untrustworthy devices. However, when the vendor information is OK, then still the implementation should verify that the certificate is valid, and its information is consistent and matches the trust criteria.

How to select which devices are to acceptable could depend on multiple factors, both cryptographic and other, and may or may not involve the CA.

CAs can define minimum security requirements for devices as a prerequisite to issue a certificate. Examples are certificates for DRM clients, as well as an app-store, which can decide to not certify certain apps.

I am still focusing on X.509 certificates here. However, I think the other security modes, such as in CoAP Raw Public Key and Pre-Shared Key, would require similar considerations.

I hope this is a better response. :-)

Best regards,
Bert