EDHOC PSK authentication

1.1. Motivation

Pre-shared key (PSK) authentication method provides a balance between security and computational efficiency. This authentication method was proposed in the first I-Ds of Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528], and was ruled out to speed out the development process. However, there is now a renewed effort to reintroduce PSK authentication, making this draft an update to the [RFC9528].¶

One prominent use case of PSK authentication in the EDHOC protocol is session resumption. This allows previously connected parties to quickly reestablish secure communication using pre-shared keys from their earlier session, reducing the overhead of full key exchange. This efficiency is beneficial in scenarios where frequent key updates are needed, such in resource-constrained environments or applications requiring high-frequency secure communications. The use of PSK authentication in EDHOC ensures that session key can be refreshed without heavy computational overhead, typically associated with public key operations, thus optimizing both performance and security.¶

The resumption capability in Extensible Authentication Protocol (EAP) leveraging EDHOC can benefit from this method. EAP-EDHOC resumption aims to provide a streamlined process for re-establishing secure sessions, reducing latency and resource consumption. By employing PSK authentication for key updates, EAP-EDHOC resumption can achieve secure session resumption, enhancing overall efficiency and user experience.¶

EDHOC with PSK authentication is also beneficial for existing systems where two nodes have been provided with a PSK from other parties out of band. This allows the nodes to perform ephemeral Diffie-Hellman to achieve Perfect Forward Secrecy (PFS), ensuring that past communications remain secure even if the PSK is compromised. The authentication provided by EDHOC prevents eavesdropping by on-path attackers, as they would need to be active participants in the communication to intercept and potentially tamper with the session. Examples could be Generic Bootstrapping Architecture (GBA) and Authenticated Key Management Architecture (AKMA) in mobile systems, or Peer and Authenticator in EAP.¶

1.2. Assumptions

3.1. Credentials

In both varaints, Initiator and Responder are assumed to have a PSK with good amount of randomness and the requirements that:¶

• Only the Initiator and the Responder have access to the PSK.¶

• The Responder is able to retrieve the PSK using ID_CRED_PSK.¶

where:¶

• ID_CRED_PSK is a COSE header map containing header parameters that can identify a pre-shared key. For example:¶

ID_CRED_PSK = {4 : h'lf' }

• CRED_PSK is a COSE_Key compatible credential, encoded as a CCS or CWT. For example:¶

{                                               /CCS/
  2 : "mydotbot",                               /sub/
  8 : {                                         /cnf/
    1 : {                                       /COSE_Key/
       1 : 4,                                   /kty/
       2 : h'32',                               /kid/
      -1 : h'50930FF462A77A3540CF546325DEA214'  /k/
    }
  }
}

The purpose of ID_CRED_PSK is to facilitate the retrieval of the PSK. It is RECOMMENDED that it uniquely identifies the CRED_PSK as the recipient might otherwise have to try several keys. If ID_CRED_PSK contains a single 'kid' parameter, then the compact encoding is applied; see Section 3.5.3.2 of [RFC9528]. The authentication credential CRED_PSK substitutes CRED_I and CRED_R specified in [RFC9529], and, when applicable, MUST follow the same guidelines described in Sections 3.5.2 and 3.5.3 of [RFC9528].¶

3.2. Variant 1

In the first variant of the method the ID_CRED_PSK is sent in the clear in the first message. Figure 1 shows the message flow of Variant 1.¶

This variant incurs minimal modifications with respect to the current methods described in [RFC9528] and the fourth message remains optional. MAC_3 is removed in message_3 and replaced by AEAD.¶

Not sure this should go here. Probably not. This approach is similar to TLS 1.3, and, consequently, has similar privacy issues. For example:¶

• Identity Leakage: neither the identity of the Initiator nor the Responder are protected against active or passive attackers. By sending the ID_CRED_PSK in the clear, the initiator reveals its identity to any eavesdropper on the network. This allows passive observers to learn which entity is attempting to connect to the server.¶

• Tracking and correlation: An attacker can use the plaintext ID_CRED_PSK to track the entity across multiple connections, even if those connections are made from different networks or at different times. This enables long-term tracking of entities.¶

• Information leakage about relationships: ID_CRED_PSK also reveals information about the relationship between the Initiator and the Responder. An observer can infer that the two parties have a pre-existing relationship and have previously agreed on a shared secret.¶

• Replay and preplay attacks: ID_CRED_PSK can facilitate replay attacks. An attacker might use the observed ID_CRED_PSK to initiate their own connection attempts, potentially leading to denial-of-service or other attacks.¶

• Downgrade attacks: If multiple PSKs are available (e.g., of varying strengths or for different purposes), an attacker might attempt to force the use of a weaker or less privacy-preserving PSK by manipulating the ID_CRED_PSK field.¶

3.3. Variant 2

The ID_CRED_PSK is sent in message_3, encrypted using a key derived from the ephemeral shared secret, G_XY. In this case, the Responder will authenticate the Initiator first, contrary to Variant 1. Figure 2 shows the message flow of Variant 2.¶

Contrary to Variant 1, this approach provides protection against passive attackers for both Initiator and Responder. message_4 remains optional, but is needed to to authenticate the Responder and achieve mutual authentication in EDHOC if not relaying on external applications, such as OSCORE.¶

4.1. Variant 1

Figure 3 lists the key derivations that differ from those specified in Section 4.1.2 of [RFC9528].¶

PRK_3e2m      = EDHOC_Extract( salt3e_2m, CRED_PSK )
PRK_4e3m      = PRK_3e2m
MAC_2         = EDHOC_KDF( PRK_3e2m,      2,  context_2,  mac_length_2 )
K_3           = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,       key_length   )
IV_3          = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,       iv_length    )

where:¶

• context_2 = <<C_R, ID_CRED_PSK, TH_2, CRED_PSK, ? EAD_2>>¶

• TH_3 = H( TH_2, PLAINTEXT_2, CRED_PSK )¶

4.2. Variant 2

Figure 4 lists the key derivations that differ from those specified in Section 4.1.2 of [RFC9528].¶

PRK_3e2m      = PRK_2e
PRK_4e3m      = EDHOC_Extract( SALT_4e3m, CRED_PSK )
KEYSTREAM_3   = EDHOC_KDF( PRK_3e2m,    TBD,  TH_3,       key_length )
K_3           = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,  key_length )
IV_3          = EDHOC_KDF( PRK_4e3m,    TBD,  TH_3,  iv_length  )

where:¶

• KEYSTREAM_3 is used to encrypt the ID_CRED_PSK in message_3.¶

• TH_3 = H( TH_2, PLAINTEXT_2, CRED_PSK )¶

• TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_PSK )¶

5.1. Variant 1

message_1 = (
  METHOD : int,
  SUITES_I : suites,
  G_X : bstr,
  C_I : bstr / -24..23,
  ID_CRED_PSK : header map // kid_value : bstr,
  ? EAD_1,
)

suites =  [ 2* int ] / int
EAD_1 = 1* ead

message_2 = (
  G_Y_CIPHERTEXT_2 : bstr,
)

message_3 = (
  CIPHERTEXT_3 : bstr,
)

message_4 = (
  CIPHERTEXT_4 : bstr,
)

5.2. Variant 2

message_2 = (
  G_Y_CIPHERTEXT_2 : bstr,
)

message_3 = (
  CIPHERTEXT_3
)

message_4 = (
  CIPHERTEXT_4 : bstr,
)

6.1. Identity protection

The current EDHOC methods protect the Initiator’s identity against active attackers and the Responder’s identity against passive attackers (See Section 9.1 of [RFC9528]). However, there are differences between the two variants described in this draft:¶

1. Variant 1: neither the Initiator's identity nor the Responder's identity are protected against active or passive attackers.¶

2. Variant 2: both the Initiator's and Responder's identities are protected against passive attackers.¶

6.2. Number of messages

The current EDHOC protocol consists of three mandatory messages and an optional fourth message. The PSK authentication method might require a compulsory message depending on which variant is employed:¶

1. Variant 1: message_4 is optional since both identities are authenticated after message_3.¶

2. Variant 2: message_4 remains optional, but mutual authentication is not guaranteed without it, or an OSCORE message or any application data that confirms that the Responder owns the PSK.¶

6.3. External Authorization Data

In both variants, the Initiator and Responder can send information in EAD_3 and EAD_4 or in OSCORE messages in parallel with message_3 and message_4. This is possible because the Initiator knows that only the Responder with access to the CRED_PSK can decrypt the information.¶

6.4. Optimization

1. Variant 1: ID_CRED_PSK is sent without encryption, saving computational resources at the cost of privacy. The exposure of ID_CRED_PSK in message_1 allows for earlier key derivation on the responder's side, potentially speeding up the process.¶

2. Variant 2: It requires encryption of ID_CRED_PSK in message_3, which implies higher computational cost.¶

6.5. Mutual Authentication

Mutual authentication is achieved at earlier stages in Variant 1, which might be important in certain applications, as well as increasing security against Denial of Service attacks or oracle attacks.¶

6.6. Attacks

1. Variant 1: it allows for earlier authentication, potentially improving resistance to some active attacks, but at the cost of reduced privacy and increased vulnerability to passive attacks and traffic analysis.-¶

2. Variant 2: it offers better privacy and resistance to passive attacks but might be more vulnerable to certain active attacks due to delayed authentication.¶

6.7. Comparison