Draft: draft-ietf-tls-external-psk-guidance

Commentary: , and . 
 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 would n'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 . ) 
 can you please take this ? 
 This text is based on the input from   . 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 : 
 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 does n't , there are security trade - offs , right ? 
 Yep . what sort of change are you looking for here ? 
 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 does n't seem like a good idea , given that the clients can then impersonate each other and listen in on each other 's traffic . 
 can you please take this ? 
 The explanation in does n'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 is n'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 do n'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 . 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 ? 
 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 . 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 : 
 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 .
Mailing list commentary: Hi Carrick , Thank you for the review . I also some comments in - line . This use - case is described in the publication by et al . . 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 . 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 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 : ) . 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 did n'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 : and drop federation . Would that work ?
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version B):
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.