After some questions about EAP-PPT in Montreal, I decided to take another look at the document. While there are a lot of comments in this message, nearly all of the issues are minor.
The only major issue is one raised during the meeting, which is how to stop abusive users. If the EAP-PPT peer is completely anonymous to every participant in the EAP and PPT conversations, then it seems impossible to detect or block abusive users. That limitation makes it extremely difficult for people to trust that they can use EAP-PPT safely in their networks. -------- Abstract It would be worth mentioning in the abstract that EAP-PPT is suitable only for use in a tunneled EAP method. Section 1 ...The tunnel-based EAP method MUST guarantee a server authenticated TLS tunnel. "guarantee" seems odd here. Perhaps MUST authenticate the server, and therefore cannot be used with any server unauthenticated modes. ... Privacy Pass tokens are issued to peer by token issuers using an Issuance Protocol [RFC9578]. Perhaps also say "out of band of EAP-PPT"? And is there any interaction between TEAP provisioning and PPT provisioning? ... A client possessing such a token is able to prove that it was able to get it issued, and is therefore presumably authentic? Since EAP-PPT is being used for authentication, it seems useful to prove more than the client got a PPT issued. Is there any way to tie this PPT to EAP? Or is the token usable for _any_ purpose once it's issued? Can a web site issue a PPT, and then the rest of the network suddenly discovers that it's valid for EAP? Perhaps the JSON blob could contain an OID or URI which indicates to the server the intended purpose of the PPT. While this document provides for an "extensions" field, it looks like no relevant extension has been defined. 2. Terminology ... EAP-PPT peer Much of the document uses "client" as a synonym for EAP-PPT peer. It would be good to add a "Client" here as a separate definition. Then, audit the document to distinguish the two-use cases. i.e. when discussing EAP, the text should use "EAP-PPT peer", and not "Client". When discussing the PPT protocol, use "Client". This consistency helps the reader distinguish the subtly different roles played by the supplicant, at different parts of the protocol exchanges. Section 4 ... This means service providers, identity providers, employers, or school/university administrators can track the individuals. It would be good to note that this complete privacy design is subject to abuse. i.e. because it's impossible to track individuals, one individual cannot be banned from the network due to abuse. ... EAP-PPT can be used for anonymous client authorization for wired and wireless network access. It would be good to note here that the combination of EAP-PPT and server authentication will authenticate both parties. Using just one method alone is insufficient. ... Since EAP-PPT method provides unilateral authentication, it qualifies to be used together with responder authentication based on public key signatures in [RFC7296] protocol. It's not clear what that means. It "qualifies"? Perhaps "it's useful", or "it's applicable"? ... [RFC7296] is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations. [RFC7296] is widely used to implement remote access VPN service in public and enterprise environments. It's not clear what the intent of this text is. "EAP-PPT can be used with IPSec"? Section 6.1 ... EAP server MUST NOT send CertificateRequest to the TLS client during the TLS handshake, when peer authentication is desired using EAP-PPT method. Perhaps also note that TLS-PSK cannot be used? Or explicitly limit this to the use-case of server certificates. ... The EAP-Response/Identity message MUST contain only realm portion Nit: say that the EAP-Response/Identity message MUST contain only an anonymized NAI as per RFC 7542 Section 2.4 (username privacy) and to 2.4 (username privacy section) ... in order to route the authentication request to the right EAP server. Nit: AAA server, as per RFC 7542 Section 3. ... It is RECOMMENDED to eliminate the identity exchange altogether if the route is known through some other means. I suggest removing this sentence, or clarifying it. The identity exchange can be eliminated when an backend authentication server knows that it will never proxy the EAP traffic such as with eduroam. But the supplicant doesn't know if it's roaming, and the authenticator doesn't know if the supplicant is local or remote. As such, it's better to just always send an initial EAP-Response/Identity in the outer EAP-TLS exchange. ... EAP-PPT uses JavaScript Object Notation (JSON) Any thought to using CBOR? It would avoid the need for encoding binary data as ASCII text. ... EAP Flexible Authentication via Secure Tunneling (EAP-FAST) I would suggest removing all references to EAP-FAST. It's not an IETF standard, and a quick net search shows that many vendors have deprecated it for years. ... Optionally, the Privacy Pass token MAY also carry extensions ([I-D.draft-ietf-privacypass-auth-scheme-extensions]) with additional metadata relevant to the EAP-PPT Server. Are there examples of what might be relevant? It's not hugely important, but it can help guide the reader as to what to do. ... As specified in [RFC3748] the initial identity request is not required, and MAY be bypassed in cases where the EAP-PPT Server can presume the identity. If the supplicant is anonymous, how can the EAP-PPT server presume the identity? If the identity is sent, should it also be an anonymized NAI? What happens if the supplicant sends a non-anonymized NAI? All user privacy is removed, right? Do we want to just forbid the use of EAP-Response/Identity with EAP-PPT? Or if an Identity is requested by an EAP-PPT server, the EAP-PPT peer MUST reply with an empty Identity. Section 6.3 ... EAP-PPT Server sends EAP-Request/PPT-Error message containing the error information like error code, error description etc. Nit: for "error code", refer to the section which defines the error codes. What's an "error description"? it's not defined. Is it possible to display textual error messages to the user? That may be useful. Section 6.4: ... the EAP-PPT server MAY decide to authorize the Peer conditionally. And then what happens? Presumably the device is placed into a quarantine network? ... The EAP-PPT server MAY optionally also include a session-timeout value in the PPT-Error, Please add a reference to 7.3.3 for PPT-Error. It's confusing to use a term before it's defined. ... The EAP-PPT peer MAY use the allotted session time to fetch a new token How? Some recommendations or guidance would be useful. Section 6.5 ... This token SHOULD be sent only once in reaction to a challenge; peers SHOULD NOT send tokens more than once, even if they receive duplicate or redundant challenges. It would be good to discuss duplicate / redundant challenges in the context of the protocol messages, instead. The issue of duplicate challenges seems more of an issue related to message format or state machine, and less about privacy. ... EAP peer and server MUST send anonymous Network Access Identifiers (NAIs) Much of this paragraph is normative text. I suggest putting normative text into a section about message formats. A "Privacy" section should instead say "privacy is preserved by requiring the use of anonymous NAIs (see section X)" ... but other constructions such as a fixed username (e.g., anonymous@realm) is allowed. Please delete this. RFC 7542 suggests that this is bad practice. Since EAP-PPT is a new EAP method, and requires user privacy, there is no benefit to allowing "anonymous@realm". ... During TLS hanshake in the first phase, EAP peer MUST send a Certificate message containing no certificates as described in Section 4.4.2 of [RFC8446], Similarly, normative text should go elsewhere. ... Similarly, use of Protected Access Credential (PAC) in EAP-FAST method (Section 3.2.2 of [RFC4851]) can potentially help the server determine peer's presence across session resumptions. I suggest deleting all references to EAP-FAST. ... For example, an EAP peer can continue to resume TLS sessions during the re-authentications as long as the client device is associated to same access point of the secure wireless LAN Perhaps also say that session resumption MUST be used only on the same Authenticator as for the original session. Section 6.7 ... While it's useful to discuss Channel-Binding, it's not clear to me that it's ever useful. I don't think it's been implemented for any other EAP method. Section 7 It would be good to define limits on allowed values. What is the minimum / maximum expect size for EAP-PPT messages, strings. What is the maximum number of elements in an array, or values for integers, etc. i.e. if there is no reason to allow 64K messages, then a recommended maximum should be given. It would be good to discuss what to do with unexpected fields, or redundant fields. Experience shows that there are many interoperability and security when these issues are left unsaid. An implementation may choose to artificially limit fields, which affects interoperability. Or, implementations may not expect fields to be large, which can result in overflows or other errors. Section 7.3.3. ... description ... Human-readable ASCII text This should be changed to UTF-8. There are few reasons to require it to be ASCII. ... session-timeout What are the recommended minimum / maximum values for session-timeout? 1 second seems small. 1 hour seems long. Section 7.3.3.1 .... What is the format of the Vendor Specific errors? i.e. how do we tell the different vendors apart? It would be good to say something like "99 is reserved for Vendor Specific errors. It MUST be associated with a JSON array of Key "vendor", and contents "PEN" and "Code". Adding a private enterprise number ensures that each vendor can define their own error. Section 8 While discussion of error handling is good, it may help to add a section on the protocol state machine. What messages are allowed in what state, what to do if invalid messages are received, etc. Even if the state machine is trivial, it may help clarify the mechanism This section could also discuss the issue of what to do when there are too many / unknown fields, etc. Section 9 It would also be good to note that there is interaction with encapsulating protocols, along with TLS fingerprinting, DHCP fingerprinting, and even TCP fingerprinting. EAP almost always goes inside of RADIUS, Diameter, IPSec, etc. Those protocols may carry identifying information such as MAC address (Calling-Station-ID). Unless the supplicant is changing its MAC address on every, it can easily be identified. There are a large number of side channels outside of EAP-PPT which can be used to identify and/or track the supplicant. It's worth noting that EAP-PPT can only solve part of the problem. What about invalid JSON? And what is either end supposed to do when a required JSON field is missing, or it gets too many JSON fields? My guess is that it should just cause the protocol exchange to fail. And perhaps most importantly, what about abuse? How does EAP-PPT allow any entity in the network to protect itself from abusive EAP-PPT peers? The user is completely anonymous, and no party in the EAP or PPT conversation can correlate any information to identify the user. So what happens when the user is abusive? How can an abusive user be identified and blocked? Perhaps Chargeable-User-Identity could be used here. I think that this issue is the single largest weakness of EAP-PPT. If the protocol design makes it impossible to stop abuse, then most people will be extremely hesitant to use it. Section 10 As noted above, there is also the issue of whether this PPT is intended for use with EAP. Is that an issue for deployments? If they issue PPT for the web (or other protocol), are those tokens implicitly usable for EAP? This section could also have a discussion of deployment issues which increase security. Perhaps this section could be listed before the "Security Considerations" section. Section 10.4 ... inherently, information about end-users could be shared between Identity Provider and Network Access Provider It would be good to summarize that information here. e.g. MAC addresses, device identity, location, etc. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
