On 2017-06-11 08:04, Paul Fremantle wrote: ~snip~
This, as stated by Ludwig, was put in to support /authz-info of ACE. It was to support the PoP keys to be used in TLS handshake between the client and the broker. But yes, the MQTT server needs to be resistant to DoS attempts pre-authorisation. MQTT needs to resist DoS before and during CONNECT (TCP holding, excess data). MQTT with /authz-info needs to implement similar resistance, for example dropping connections that fail to authenticate in a timely fashion, and blocking repeated offenders, so there's little difference in theory - although resistance pre-CONNECT may already exist in some broker implementations. A discussion can be put in Security ConsiderationsI agree that a discussion of the pros and cons of this approach would be valuable. I'm not clear on the benefits of using POP keys in TLS handshakes. Can you please point me where to look?
The idea is to use the key used in the TLS handshake (e.g. the pre-shared key when an RFC 4279 handshake is used or the raw public key for a RFC 7250 handshake) as the POP key. This way the TLS handshake provides the proof of possession (for asymmetric keys you need to require client authentication).
Have a look at https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07 for more background on PoP.
/Ludwig -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
