Hello Ludwig, This was MQTT-SN-over-DTLS was on our agenda when first we started out. However, at that time there was not much take-up of MQTT-SN in practice (not sure that changed). If there is sufficient interest in the group, would make sense to do that as well, and theoretically, it would be a more natural fit to ACE. Thanks, --Cigdem
On Thu, May 23, 2019 at 7:29 AM Ludwig Seitz <[email protected]> wrote: > On 21/05/2019 22:35, Cigdem Sengul wrote: > > Thank you for your comments. I see that we tried to cover too many > > options in the draft, and things got mixed up.I tried to clarify inline. > > > > * So as a client I get a token from the AS. For the first run, > > assume that > > it has a RPK in it. > > * I now connect to the server using TLS. > > Question #1 - Am I doing client authentication at this > > point in TLS? > > This is what is happening for all of the current profiles, but it is > not > > clear that this is happening for this profile. The answer appears > to be > > both yes and no. > > > > The basic method we were thinking: > > > > > > 1. We have not assumed client-side certificates for authenticating > > clients during TLS handshake. RS uses a server-side certificate. > > > > One quick question: If I understand it correctly there is a variant of > MQTT using UDP (MQTT-SN). Since TLS and TCP are not exactly > "constrained-friendly", would it make sense to look at that as well to > define a "MQTT-SN-over-DTLS-based" profile? > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
