Original text:
entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova): <del> Group chats.  In this use-case, the membership of a group is confirmed by the possession of a PSK distributed out-of-band to the group participants.  Members can then establish peer-to-peer connections with each other using the external PSK.  It is important to note that any node of the group can behave as a TLS client or server. Internet of Things (IoT).  In this use-case, resource-constrained IoT devices act as TLS clients and share the same PSK.  The devices use this PSK for quickly establishing connections with a central server.  Such a scheme ensures that the client IoT devices are legitimate members of the system.  To perform rare system specific operations that require a higher security level, the central server can request resource-intensive client authentication with the usage of a certificate after successfully establishing the connection with a PSK. </del>  6.1.

Reviewer comments:
, and .
NAME does this address your (other) comments?
I think this adds really helpful context to what would otherwise be confusing on its own, thanks.
(Also adding this question from the email.) The draft states: "PSK provisioning systems are often constrained in application-specific ways. For example, although one goal of provisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distribute pair-wise shared keys to achieve this." Why wouldn't a system want to distribute pair-wise keys? What application-specific constraint would warrant that? (I'm imagining, for instance, that maybe that would overload the network or something, but the reason should probably be explained rather than left to the imagination.)
NAME can you please take this?
This text is based on the input from Björn Haase. Essentially, he indicated that some industrial control deployments do not want to have O(n^2) keys for a system with n nodes, but they do want to minimize sharing. I am fine with changing it to "might not want to" or removing this constraint completely. Also answered on the mailing list here: URL
Ah, that seems like an important point to mention. It makes sense that provisioning O(n^2) keys would be overburdensome on a system, but if it doesn't, there are security trade-offs, right?
Yep. NAME what sort of change are you looking for here?
NAME change works for me.
(This question is copied from my email.) The draft states: "In this use-case, resource-constrained IoT devices act as TLS clients and share the same PSK. The devices use this PSK for quickly establishing connections with a central server. Such a scheme ensures that the client IoT devices are legitimate members of the system." If the IoT devices only talk to a central server and not each other, why do they all need the same PSK? That doesn't seem like a good idea, given that the clients can then impersonate each other and listen in on each other's traffic.
NAME can you please take this?
The explanation in URL doesn't address why it's okay or desirable for all the clients to have the same PSK. The clients are constrained, being IoT devices, but the server isn't, and presumably can handle n PSKs for n clients.
The best argument I can come up with for why a server might want all devices to have the same key is if there are many devices and a high rate of turnover. Rather than trying to keep track of rapidly changing list of keys, perhaps it is easier to just use a single key, especially if there is a high penalty if a device is unable to connect. Further, if the devices have a way of upgrading to a more secure connection when necessary, then the central server may not care if devices can impersonate one another. Not sure it's very convincing, but perhaps at least plausible?
I don't think we need to rationalize the use case. The point of this section is to document known use cases, not justify them, and to provide recommendations for using PSKs in such circumstances. NAME I'm not sure what action you're looking for here. Justification is out of scope, I think.
You can close this then, since this relates to the discussion elsewhere about justification.
(This question is copied from my email.) The draft states: "To perform rare system specific operations that require a higher security level, the central server can request resource-intensive client authentication with the usage of a certificate after successfully establishing the connection with a PSK." If you're going to authenticate with a cert, why bother preceding that with an authentication with a PSK?
NAME can you please take this?
and this refer to the same use-case and can be merged. This use-case is described in the publication by Akhmetzyanova et al. URL See section 4. In the scenario described by the authors, resource-constrained IoT devices are TLS clients. The PSK is used for authenticating the central server and client membership of the system. Only for rare device-specific operations requiring a higher-security level (such as device firmware update), the server can request resource-intensive client authentication with certificates after successfully establishing the connection with PSK. This deployment may seem somewhat artificial but it was necessary in the paper to explain the possible attack scenarios. Also answered on the mailing list here: URL
That rephrases the content in the draft; I guess what I'm asking for is a brief explanation as to why authenticating the client with a certificate is necessary to circumvent those attack scenarios. Hi Carrick, Thank you for the review. I also added some comments in-line. On 8/18/20 6:26 PM, Christopher Wood wrote: This use-case is described in the publication by Akhmetzyanova et al. URL See section 4. In the scenario described by the authors, resource-constrained IoT devices are TLS clients. The PSK is used for authenticating the central server and client membership of the system. Only for rare device-specific operations requiring a higher-security level (such as device firmware update), the server can request resource-intensive client authentication with certificates after successfully establishing the connection with PSK. This deployment may seem somewhat artificial but it was necessary in the paper to explain the possible attack scenarios. This text is based on the input from Björn Haase. Essentially, he indicated that some industrial control deployments do not want to have O(n^2) keys for a system with n nodes, but they do want to minimize sharing. I am fine with changing it to "might not want to" or removing this constraint completely. A citation for EAP-TLS-PSK is added in the github version of the document. I agree that "routable" identities is not something obvious and could be better explained. In standard AAA (Authentication, Authorization and Accounting) architecture, client devices send an identity for network access authentication. These identities are in the form of a Network Access Identifier (define in RFC 7542: URL). Nodes in the network such as access points (also called as authenticators) look at the identity (mostly the domain name suffix at the end of the identity) to determine if they should proceed with the authentication request and for figuring out the appropriate EAP server where the authentication request should be sent. Perhaps that sentence could be re-written as: "PSK identities may sometimes need to have a domain name suffix, as is currently under discussion for EAP-TLS-PSK [I-D.mattsson-emu-eap-tls-psk]". I didn't find any standard definition of federation even though many RFCs have used them in the past (RFCs 2552,3313,7532). We could add a reference to roaming defined in RFC 2904: URL and drop federation. Would that work? --Mohit

Revised text:
entities.  Some examples below (as noted by Akhmetzyanova et al.Akhmetzyanova):  <ins> Group chats.  In this use-case, group participants may be provisioned an external PSK out-of-band for establishing authenticated connections with other members of the group. Internet of Things (IoT) and devices with limited computational capabilities.  Many PSK provisioning examples are possible in this use-case.  For example, in a given setting, IoT devices may all share the same PSK and use it to communicate with a central server (one key for n devices), have their own key for communicating with a central server (n keys for n devices), or have pairwise keys for communicating with each other (n^2 keys for n devices). The exact provisioning process depends on the system requirements and threat model.  Generally, use of a single PSK shared between more than one node is not recommended, even if other accommodations are made, such as client certificate authentication after PSK-based connection establishment.  See recommendations. </ins> 6.1.