Hello Marco, Responses inline. > > [CS: This is because the Authentication Data explained under 2.2.4 is > binary data. The > binary data in MQTT is represented by a two-byte integer length, which > indicates the number of data bytes, followed by that number of > bytes. > So, we have the total length of the entire Authentication Data, > Token length + token + (total length - token length) of MAC data. > I hope this is more clear. > > Do you think I should repeat what binary data is at the subsections rather > than explaining in 2.2.4? > ] > > > ==>MT > So the Authentication Data includes some <Length ; Content> binary data, > possibly followed by some extra data (here a MAC/Signature). Correct? > I think it's worth clarifying this when introducing the Authentication > Data, and say what is part of the binary data here in Section 2.2.4.1. > <== > > [CS: I think I may introduce ASCII art to explain this. The content of Authentication Data for 2.2.4.1 is: Token length (2B) +token+Mac computed over the content from the TLS exporter. i.e, it is inclusive of the MAC. T
Actually, Authentication Data is defined before the subsections 2.2.4.1 and 2.2.4.2, under 2.2.4, because it is common to both subsections, just its content varies. The text says: "The Authentication Method is followed by the Authentication Data, which has a property identifier 22 (0x16) and is binary data. The binary data in MQTT is represented by a two-byte integer length, which indicates the number of data bytes, followed by that number of bytes." Then, the subsection explains what is in the Authentication Data content (ie. binary data part) and may include additional length fields. I think this is where the confusion stems from - the multiple length fields. ] > > >> [Section 2.2.4.2] >> >> * Shouldn't the Authentication Data in the AUTH message from the server >> start with a 2-byte server nonce length? >> > [CS: the client is calculating a MAC over its nonce and server nonce and > sending it back, with the information of its nonce. > I assumed the RS would remember its nonce length] > > > ==>MT > I was referring to the AUTH packet from the server, including its RS > challenge. > > The message is still including Authentication Data, and in any other case > this seems to start with a 2-byte length field, as also described in > Section 2.2.4. > > If that length field is actually optional, I can see it might be omitted > here, since the client is supposed to get always an 8-byte nonce from the > server. > <== > > [CS: That was the reason - the spec defined the nonce as 8-byte. And as it did not make its size optional, the Authentication Data does not include the nonce size. ] > > [CS: Has my previous explanation clarified this? > > client_nonce length + nonce > (the size of AUTH DATA - client_nonce_length) of MAC of > (client_nonce+server nonce) > > > ==>MT > Yes, I think similar clarifications would help here in Section 2.2.4.2. > <== >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
