Some additional comments inline: From: Ace <ace-boun...@ietf.org> on behalf of Michael Richardson <mcr+i...@sandelman.ca> Date: Wednesday, 12 October 2022 at 15:24 To: l...@ietf.org <l...@ietf.org> Cc: a...@ietf.org <a...@ietf.org>, anima@ietf.org <anima@ietf.org> Subject: [Ace] ace-ake-auth updates for latest EDHOC principles
The authors of draft-selander-ace-ake-auth have been discussing how to update this draft to reflect some of the changes in EDHOC. Specifically, there is a concern that ace-ake-auth reveals too much in message_1, things which EDHOC has worked hard to keep private. One planned change in the next version is to shift the trust model from: * the trusted third party, W, is trusted to decide to which authenticator V the identity of the device U is revealed to: * the device U decides to which authenticator V it reveals its identity. Since the authentication credential of U may be large it is still desirable that V can obtain it from W rather than over the constrained link between U and V, but - to match the changed trust assumption above - at a different time in the protocol: after message_3 instead of before message_2. For those that don't know ace-ake-auth, it fits into the "Ultra-constrained" onboarding column for the diagram that was part of https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-03 (and was in the IoT-Dir wiki, which needs to be resurrected. The diagram is also visible at: https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-bbfeee37309f6b5e&q=1&e=ed56df95-0487-4240-99b5-7a62a7af1bd5&u=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fenrollment-roadmap%2Fblob%2Fmaster%2Ftechnology-components.svg ) The ACE connection is that the backend (aka "BRSKI-MASA" protocol equivalent) was leveraged against the ACE mechanism. There is now some reconsideration here. Fundamentally, it would be nice to know where the document adoption is going so that we'd know where to have public discussions about the trade-offs. (please note reply-to) Michael’s way of saying that LAKE is a natural candidate. This draft is building on EDHOC and matches a request from the LAKE WG to produce an example showing how the External Authorization Data message fields can be applied. The location of the MASA (aka "W" in the document) is provided in the clear during message_1, with the actual device serial number encrypted to W using a static DH key that the pledge ("U") has been provisioned with. It would be nice to move some of this from message_1 to message_3, which would guard better against on-path attacks that impersonate V. See above. Göran The URL provided during message_1 is visible to any observers, and since this is onboarding, any network privacy is not yet applicable. OTH, the authorization step needs to complete before message_2 can properly be formed, as it contains enough of the RFC8366 constrained-voucher semantics that it allows the pledge (U) to authenticate V. Knowing the identity of the MASA may tell you a lot about the device in question. This is a place where having many MASA outsourced to a big MASA helps with privacy. It's also a place where perhaps oblivious-HTTP might help. There is a question about what the security policy of W is. Is it TOFU-ish, aka promiscious MASA, or does *it* know which device has been sold to whom? Also, the URL for the MASA is ideally very very short :-) -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
