idnits 2.17.00 (12 Aug 2021) /tmp/idnits37913/draft-rieckers-emu-eap-noob-observations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 169: '...of these objects MUST be defined by th...' RFC 2119 keyword, line 172: '...tates: "The peer MAY include in PeerIn...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J.-F. Rieckers 3 Internet-Draft DFN 4 Intended status: Informational 7 March 2022 5 Expires: 8 September 2022 7 Observations about EAP-NOOB (RFC 9140) 8 draft-rieckers-emu-eap-noob-observations-00 10 Abstract 12 This memo is a random list of things the author noticed about EAP- 13 NOOB when looking at the draft and running the implementation while 14 capturing the packets (https://github.com/Vogeltak/hostap). 16 Most of the statements were written down before the author started 17 the implementation. By the time of writing this draft, a mostly 18 complete server implementation has been written. The implementation- 19 specific remarks are mostly thoughts the author had while planning 20 their own implementation. 22 About This Document 24 This note is to be removed before publishing as an RFC. 26 Status information for this document may be found at 27 https://datatracker.ietf.org/doc/draft-rieckers-emu-eap-noob- 28 observations/. 30 Discussion of this document takes place on the EAP Method Update 31 (emu) Working Group mailing list (mailto:emu@ietf.org), which is 32 archived at https://mailarchive.ietf.org/arch/browse/emu/. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Areas of observations . . . . . . . . . . . . . . . . . . . . 2 68 2.1. Why use JSON? . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. IANA-Registries . . . . . . . . . . . . . . . . . . . . . 3 70 2.3. Unnecessarily long messages . . . . . . . . . . . . . . . 4 71 2.4. Unclear status of ServerInfo and PeerInfo . . . . . . . . 4 72 2.5. Number of messages exchanged . . . . . . . . . . . . . . 5 73 2.6. Reconnecting State in state machine . . . . . . . . . . . 6 74 2.7. Missing Specification . . . . . . . . . . . . . . . . . . 6 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 5.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 81 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 (see abstract) 88 2. Areas of observations 89 2.1. Why use JSON? 91 The author's initial reaction when they first read the draft was: Why 92 use JSON and not a binary protocol? Almost no advantages of using 93 JSON (dynamic keys, reordering, flexible and possible deep structure) 94 are needed for or used in this protocol, while on the other hand the 95 JSON serialization is problematic for the calculation of MAC/Hoob/... 96 Especially the need to extract the JSON value of the PeerInfo and 97 ServerInfo field may cause problems in the Hash/HMAC calculation, if 98 peer and server do not agree on a JSON serialization. 100 The protocol has many static parts (always the field "Type", mostly 101 fixed parameters depending on the type, ...), so it seems as if the 102 number of bytes and the parsing effort could be significantly reduced 103 if static protocol messages (e.g. like in the TLS Handshake messages) 104 were used. 106 If the message format should be more flexible, CBOR seems to be a 107 good idea as well. Here a simple map (best with numbers as keys) 108 could be used, combined with deterministic encoding (Section 4.2 of 109 [RFC8949]). 111 2.2. IANA-Registries 113 EAP-NOOB has a striking number of IANA-registered protocol parameters 114 with a dedicated IANA registry page only for EAP-NOOB. At first 115 glance this seems a bit odd, since the protocol does not seem to be 116 this complex. 118 Especially the choice for a designated registry for cryptosuites 119 seems odd. With the current situation, every new curve has to be 120 respecified instead of just using existing registries. This requires 121 implementers to update their EAP-NOOB implementation instead of just 122 updating the cryptographic library behind it. The current 123 specification specifies only two cryptosuites, which may not be 124 feasible for all use cases, especially if higher security levels are 125 required. 127 As a possible alternative, the COSE algorithms registry provides 128 short identifiers for many relevant parameters. 130 Another odd thing is the Server-/PeerInfo Registry, see Section 2.4. 132 2.3. Unnecessarily long messages 134 It seems that the protocol uses an unnecessarily high number of bytes 135 to transfer the information. Though this should not lead to issues 136 on the EAP/WPA2 level, it seems that the protocol is not well-suited 137 for constrained devices. 139 This is especially prominent for the encoding of the ServerInfo and 140 PeerInfo fields. Since the IANA policy is "Specification required", 141 shorter identifiers could have been used instead of human-readable 142 names, leading to shorter messages. 144 The author was also a little confused about the reason why the PeerId 145 is always retransmitted. Other EAP-Methods do just fine without any 146 explicit information to identify the exact EAP instance running, so 147 it seems a bit odd that the server and the peer keep telling each 148 other what the PeerId is. From the author's understanding, the 149 PeerId only has to be transmitted once, either in the first EAP-NOOB 150 message from the peer to the server, if the PeerId was assigned in a 151 previous EAP-NOOB conversation, or in the second EAP-NOOB message 152 from the server to the peer, if a new PeerId has to be allocated. 153 The PeerId can then be saved to the current EAP state information. 154 This also seems useful to prevent bad implementations where the 155 PeerId is not checked every time (since it is always the same 156 anyway), but for the calculation of Hoob/..., only the one 157 transmitted last is used, which an attacker could have modified. 158 However, this is a random thought of how broken implementations could 159 be; the author has not yet analyzed the actual attack vector or its 160 effects. 162 In the server implementation by the author, the PeerId sent by the 163 client is ignored in all messages except the aforementioned. 165 2.4. Unclear status of ServerInfo and PeerInfo 167 The specification is somewhat ambiguous regarding the ServerInfo and 168 PeerInfo fields. Section 3.3.2 of [RFC9140] specifies them as "The 169 format and semantics of these objects MUST be defined by the 170 application that uses the EAP-NOOB method." On the other hand, 171 specific fields are defined in Section 5.4 and 5.5. In Section 6.7 172 (Channel Binding) the RFC states: "The peer MAY include in PeerInfo 173 any data items that it wants to bind to the EAP-NOOB association and 174 to the exported keys." 176 This is especially interesting for the calculation of Hoob/MACs/ 177 MACp/... since the PeerInfo and ServerInfo fields are encoded as 178 JSON, both the Server and the Peer have to somehow agree on a 179 serialization of the JSON object inside. This could become extremely 180 tricky once either side sends attributes the other one does not 181 expect, e.g. a field with an additional object inside. Since it is 182 JSON and not a JSON-encoded string, the client has to parse the whole 183 JSON tree in order to compute the correct Hoob/MACs/MACp/... value. 184 Again, this could be easier with other data representation formats. 185 With CBOR, the specification could simply use the bytes, which the 186 CBOR parser could easily distinguish. Additionally, [RFC8949] 187 specifies a canonical encoding, so both peer and server can generate 188 the Hash/HMAC deterministically, even if the implementation only 189 saves the content of the fields, not the encoded message. 191 Since the IANA registration procedure for PeerInfo/ServerInfo is 192 "Specification required", additional use cases for these fields 193 cannot easily be added. For a Masters project at the University of 194 Bremen, students are looking into MUD ([RFC8520]), and it would be 195 interesting to transmit the MUD URL in the PeerInfo, or the server 196 could transmit some initial (public) configuration parameters for the 197 device, e.g. the URI for a SmartHome controller. Since RFC 9140 does 198 not specify how to deal with unexpected or unknown fields, this could 199 lead to unexpected behavior, if the peer does not understand the 200 server's parameters. 202 2.5. Number of messages exchanged 204 The number of messages exchanged seems to be on the high side. 206 For the initial exchange this leads to 4 roundtrips, for the 207 reconnect exchange 5 roundtrips, which seems unnecessarily high. 208 (The counts given start with the EAP-Response/Identity packet.) 210 Let's describe one straightforward way to reduce the number of 211 messages needed, primarily for the initial handshake: 213 The server could send its supported Versions, Cryptosuites and 214 Directions in the first EAP-NOOB message. 216 If the peer is in the initial state, in the last message of the 217 common handshake, the peer already knows that it wants to negotiate a 218 new set of connection parameters, so it could already transmit its 219 ECDHE parameters along with the PeerInfo. If the server had already 220 sent its supported versions, cryptosuites and directions, it could 221 already choose the suitable methods. 223 In the answer the server could then transmit its ServerInfo and its 224 ECDHE parameters. This saves at least one roundtrip. It also gives 225 the server the ability to send different ServerInfo parameters 226 depending on the type of the peer device. This would also enable 227 configuration provisioning; for instance, if a light bulb is 228 connected, the server could already send the address of the light 229 controller to which the bulb should connect to once the EAP-NOOB 230 connection is established. (See previous point on ServerInfo and 231 PeerInfo.) 233 If the peer is already connected, sending the supported versions and 234 cryptosuites in the first message would also give the peer enough 235 information to decide whether a renegotiation with a newer version or 236 updated cryptographic keys is necessary and could already transmit 237 new ECDHE parameters. 239 Details of these thoughts have been put into the draft 240 [I-D.draft-rieckers-emu-eap-ute]. In this draft, all standard 241 exchanges consist of 3 roundtrips. 243 2.6. Reconnecting State in state machine 245 The existence of the "Reconnecting" state in the state diagram is a 246 bit confusing, since the differentiation between Reconnecting and 247 Registered State does not serve a further purpose other than to 248 determine if the peer is currently connected to a network. For the 249 server, the difference between Reconnecting and Registered state 250 should not be relevant at all, since it is never the initiator of the 251 EAP conversation. Once the peer loses its connection, a reconnect 252 attempt has to be started anyway, so the peer should never start an 253 EAP-NOOB handshake when in state 4 (this behavior is also specified). 254 Specifying this state may help with implementation, but it might also 255 confuse the implementer. 257 2.7. Missing Specification 259 RFC 9140 never explicitly specifies which value should be used for 260 the Protocol Version field. Only example values are given in 261 Section 3.3.2 for Vers and Verp, from which the version number 1 262 could be guessed. 264 3. IANA Considerations 266 This memo includes no request to IANA. 268 4. Security Considerations 270 This document discusses a specification that is intended to provide 271 security when initiating Internet access. 273 5. References 275 5.1. Normative References 277 [RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band 278 Authentication for EAP (EAP-NOOB)", RFC 9140, 279 DOI 10.17487/RFC9140, December 2021, 280 . 282 5.2. Informative References 284 [I-D.draft-rieckers-emu-eap-ute] 285 Rieckers, J.-F., "User-assisted Trust Establishment (EAP- 286 UTE)", Work in Progress, Internet-Draft, draft-rieckers- 287 emu-eap-ute-00, 2022, . 290 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 291 Description Specification", RFC 8520, 292 DOI 10.17487/RFC8520, March 2019, 293 . 295 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 296 Representation (CBOR)", STD 94, RFC 8949, 297 DOI 10.17487/RFC8949, December 2020, 298 . 300 Acknowledgements 302 TBD 304 Contributors 306 Carsten Bormann 307 Universität Bremen TZI 308 Postfach 330440 309 D-28359 Bremen 310 Germany 311 Phone: +49-421-218-63921 312 Email: cabo@tzi.org 314 Author's Address 316 Jan-Frederik Rieckers 317 Deutsches Forschungsnetz | German National Research and Education Network 318 Alexanderplatz 1 319 10178 Berlin 320 Germany 321 Email: rieckers@dfn.de 322 URI: www.dfn.de