学习 MQTT v5 中的随手笔记
物联网应用中，安全设计很重要。敏感数据泄露或是边缘设备非法控制等事故是不可接受的。
当前物联网局限：
1、安全性与高性能 不能兼顾
2、加密算法需要更多算力，而物联网设备性能非常有限
3、物联网终网络添加一般较差
对此：MQTT 协议 提供了简单认证和增强认证，方便再应用层验证设备。
简单认证：
Mqtt connect 报文使用username、password 支持基本网络连接认证，被称为简单认证。也被用来承载其他形式的认证，例如把密码作为令牌（Token）传递。
简单认证对客户端、服务端的算力占用低，对安全性要求不高。计算资源紧张的业务可以使用简单认证。
缺点: 简单认证中，客户端和服务端都知道一个用户名和密码，在不对信道加密的前提下，无论是否直接使用明文传输username、password，还是给password 加个Hash256都容易被攻击。
增强认证：
基于更强的安全性考虑，增强认证包含 质询/响应风格 的认证，可实现客户端和服务端双向认证，服务器可以验证连接的客户端是否真实，客户端也可以验证服务器是否真实。
增强认证依赖于认证方法和认证数据来完成整个认证过程，认证方法为：SASL机制，使用一个注册过的名称便于信息交换。但认证方法不限于使用已注册SASL机制，服务器和客户端可以约定使用任何质询/响应风格的认证。
认证方法：
认证方法是一个UTF-8的字符串，用于指定身份验证方式，客户端和服务器需要同时支持指定的认证方法。客户端通过connect报文中添加认证方法字段来启动增强认证。
增强认证过程中客户端和服务器交换的报文都需要包含认证方法字段，并且认证方法必须与connect报文一致。
认证数据：
认证数据是二进制信息，用于传递加密机密或协议步骤的多次迭代。认证数据的内容高度依赖于认证方法的具体实现。
增强认证流程：
增强认证需要客户端与服务器之间多次交换认证数据，因此，Mqtt v5 新增了auth 报文来实现这个需求。增强认证是基于connect报文、connack报文以及auth报文类型实现的，三种报文都需要携带认证方法与认证数据达成双向认证的目的。
要开启增强认证流程，
需要客户端向服务器发送包含了认证方法字段的connect报文，
服务器收到connect报文后，它可以与客户端通过auth报文继续交换认证数据，
在认证完成后向客户端发送connack报文。
SCRAM 例：
client -> service : connect 认证方法=“SCRAM-SHA-1”,认证数据=client-first-data
service -> client : auth原因码=0x18，认证方法=“SCRAM-SHA-1”，认证数据=service-first-data
client -> service : auth原因码=0x18，认证方法=“SCRAM-SHA-1”,认证数据=client-final-data
service -> client : connack原因码=0，认证方法=“SCRAM-SHA-1”，认证数据=service-final-data
kerberos例：
client -> service : connect 认证方法=“GS2-KRB5”
service -> client : auth原因码=0x18，认证方法=“GS2-KRB5”
client -> service : auth原因码=0x18，认证方法=“GS2-KRB5”，认证数据=initial context token
service -> client : auth原因码=0x18，认证方法=“GS2-KRB5”, 认证数据=reply context token
client -> service : auth原因码=0x18，认证方法=“GS2-KRB5”
service -> client : connack原因码=0，认证方法=“GS2-KRB5”,认证数据=outcome of authentication
增强认证过程中，客户端与服务器端要进行多次认证数据的交换，每次交换都需要通过认证算法对认证数据进行加解密的计算，它需要更多的计算资源以及更稳定网络环境，因此它不适合算力薄弱、网络波动大的边缘设备，而支持增强认证的Mqtt服务器也需要准备更多的计算资源来应对大量的连接。
重新认证：
增强认证完成之后，客户端可以在任意时间通过发送auth报文发起重新认证，重新认证开始后，同增强认证一样，客户端与服务器通过交换auth报文来交换认证数据，知道服务器向客户端发送原因码0x00(成功）的auth报文表示重新认证成功。注意：重新认证的认证方法与增强认证一致。
在重新认证过程中，客户端与服务器的其他报文可以继续使用之前的认证。