On Feb 19, 2026, at 9:53 AM, Bart Brinckman (bbrinckm) <[email protected]> wrote: > Thanks again for your comments! It's been a while since you sent this. We've > now updated the draft based on your feedback. Here are also the responses to > your comments/questions. Pls let us know if you see any remaining issues we > should address.
Thanks. I have some minor comments below. Unless I've otherwise commented, the changes look good. > 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? > > [P&B] In principle, the token can be redeemed for an authentication purpose > by any attested client including a web browser or proxy client or 802.1X > supplicant. For example, web browsers apps use privacy pass token as an > alternative to CAPTCHA. However, it’s up to the EAP-PPT server to construct a > token challenge for EAP-PPT authentication only so a peer can get a token > issued for EAP-PPT authentication only. So we can have token issued for > multiple purposes or for distinct purposes, depending on how the token > challenge is constructed. It would be useful to explain how this is done, and what security impacts exist if this isn't done. > 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. > > [P&B] The token is tied to the token challenge sent by the EAP-PPT server. > The token challenge structures contains issuer's name and redemption context. > So if required, the server can populate these fields with relevant values to > indicate the purpose. The See Token Challenge structure here - > https://www.rfc-editor.org/rfc/rfc9577#section-2.1.1. Extensions can be use > to transfer information additional to the intended purpose of the token. Examples could help implementers here. > ... 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. > > [P&B] is EAP-FAST not RFC4851? There are examples of device and network/AAA > vendors supporting it. RFC4851 is informational. Referencing a standards-track document would be better. > 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? > > [P&B] That depends on the policy of that network. It could be a quarantine > network that only allows access to an issuance service for a limited amount > of time, or it could be full internet access for a limited amount of time Adding explanatory text would help. > 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. > > [P&B] Even with duplicate/redundant challenge, the token that peer produces > is unique since it is cryptographically generated using a fresh random nonce. > It is very likely that most times the server will send same set of challenges > during every authentication, and in response, the peer will send a unique > token that's bound to one of the challenges. > It implicates user's privacy when peer double-spends the token as it tells > the server the same user is re-visiting the network. By saying "This token > SHOULD be sent only once in reaction to a challenge", we are recommending > peer implementation to prevent double-spending. Adding the above text as an explanation would make the issue clearer for the reader. > 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. > > [P&B] We do not really understand why the document should explicitly specify > that. The protocol already specifies the length of the message to expect, so > any implementation that finds noncompliance in the messages should bail out, > reporting an error. We have not really found this in other EAP methods. Can > you point us to an example? Historic EAP methods don't have json blobs, which are essentially free-form text. > > 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. > > [P&B] If an unexpected field is encountered that is not compliant to the > spec, the implementation should always break off the EAP conversation. Does > this need to be explicitly mentioned? Definitely, yes. > 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. > > [P&B] We wanted to allow a vendor to register a code in this range and > specific the error description. The IANA section should then define a vendor range, and a method for allocating them. > 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. > > [P&B] We defined the message flow in the protocol chapter. If there are any > unknown fields then as per the previous comment related to this question, the > implementation should always break off the EAP conversation. Do you believe > there is somethign missing in the message flow in the protocol section? Not really. My comments were more trying to ensure that the entire protocol exchange was documented. i.e. if a document just says "here's how it's supposed to work", then implementers are left with no guidance when they run into situations outside of the expected workflow. So it's useful to say instead "it's supposed to work this way, and if it doesn't, here's what to do" > 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. > > [P&B] We provide an overview on what the problem is EAP-PPT solves in the > motivation section. In the privacy section of the protocol chapter, we > provide guidance on what to do and not to do in the outer EAP-method to > ensure privacy. You are correct, there are many ways that potentially some > tracking can be achieved of a client, down to Layer 2. We did not want this > spec to particularly enumerate them, nor would we be able to do that > exhaustively. There's no need for an exhaustive list. But it would be good to mention that EAP-PPT is transported in other protocols, which do not have the privacy-preserving design of EAP-PPT. Alan DeKok. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
