



Internet Engineering Task Force                              M. Sobolyev
Internet-Draft                                      Sippy Software, Inc.
Intended status: Standards Track                             29 May 2026
Expires: 30 November 2026


 SIP Digest Authentication with X25519 Shared Secrets and Ristretto255
                             Schnorr Proofs
          draft-sip-digest-auth-x25519-ristretto255-schnorr-00

Abstract

   This document defines three Session Initiation Protocol (SIP) Digest
   authentication algorithms that replace password-derived Digest
   secrets with public-key-based authentication material.  Two
   algorithms derive a response secret from an X25519 shared secret, and
   one algorithm uses a Fiat-Shamir Schnorr proof over the ristretto255
   group.

   The mechanisms defined here preserve the existing SIP Digest
   challenge and authorization header flow while adding Digest
   parameters that carry public keys and, optionally, an authenticated
   server challenge proof.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Sobolyev                Expires 30 November 2026                [Page 1]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   4.  Digest Parameters and Syntax  . . . . . . . . . . . . . . . .   5
     4.1.  server-pubkey . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  client-pubkey . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  client-challenge  . . . . . . . . . . . . . . . . . . . .   6
     4.4.  server-response . . . . . . . . . . . . . . . . . . . . .   7
   5.  Transcript Encoding . . . . . . . . . . . . . . . . . . . . .   7
   6.  Common Digest Fields  . . . . . . . . . . . . . . . . . . . .   8
   7.  Algorithm: X25519-HKDF-SHA256 . . . . . . . . . . . . . . . .   8
     7.1.  Challenge . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  Authorization Response  . . . . . . . . . . . . . . . . .   9
     7.3.  Shared Secret Calculation . . . . . . . . . . . . . . . .   9
     7.4.  Response Calculation  . . . . . . . . . . . . . . . . . .  10
   8.  Algorithm: X25519-HMAC-SHA256 . . . . . . . . . . . . . . . .  10
     8.1.  Challenge . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.2.  Authorization Response  . . . . . . . . . . . . . . . . .  11
     8.3.  Shared Secret Calculation . . . . . . . . . . . . . . . .  11
     8.4.  HMAC Transcript . . . . . . . . . . . . . . . . . . . . .  12
   9.  Algorithm: R25519-SCHNORR-SHA256  . . . . . . . . . . . . . .  12
     9.1.  Optional Authenticated Server Challenge Request . . . . .  12
     9.2.  Challenge . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.3.  Authenticated Server Challenge Proof  . . . . . . . . . .  13
     9.4.  Authorization Proof . . . . . . . . . . . . . . . . . . .  14
   10. Verification Rules  . . . . . . . . . . . . . . . . . . . . .  14
   11. Replay Protection . . . . . . . . . . . . . . . . . . . . . .  15
   12. Body Integrity  . . . . . . . . . . . . . . . . . . . . . . .  16
   13. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  Initial Request Asking for Authenticated Server
            Challenge  . . . . . . . . . . . . . . . . . . . . . . .  16
     13.2.  Authenticated R25519-SCHNORR-SHA256 Challenge  . . . . .  16
     13.3.  R25519-SCHNORR-SHA256 Authorization with Username  . . .  17
     13.4.  R25519-SCHNORR-SHA256 Authorization without Username . .  17
     13.5.  X25519-HKDF-SHA256 Challenge . . . . . . . . . . . . . .  17
     13.6.  X25519-HKDF-SHA256 Authorization with Username . . . . .  18
     13.7.  X25519-HKDF-SHA256 Authorization without Username  . . .  18



Sobolyev                Expires 30 November 2026                [Page 2]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   15. Implementation Notes  . . . . . . . . . . . . . . . . . . . .  19
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   17. Normative References  . . . . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   This document defines the following SIP Digest authentication
   algorithm tokens:

   *  X25519-HKDF-SHA256

   *  X25519-HMAC-SHA256

   *  R25519-SCHNORR-SHA256

   The algorithms are intended for deployments where the User Agent
   Client (UAC) and User Agent Server (UAS), or a proxy acting as the
   authenticating server, have pre-provisioned trust in each other's
   public keys.  They do not define certificate discovery, enrollment,
   or authorization policy.

   The X25519 algorithms derive authentication material from the shared
   secret computed by [RFC7748] X25519.  The ristretto255 algorithm uses
   a Schnorr-style non-interactive proof over the group defined by
   [RFC9496].

   X25519-HKDF-SHA256 and X25519-HMAC-SHA256 preserve the original SIP
   Digest flow: the UAS sends a challenge and the UAC sends an
   authorization response after validating the challenged server public
   key against local policy.  R25519-SCHNORR-SHA256 adds a new
   capability: the UAC can request that the UAS pre-authenticate the
   challenge using server-response before the UAC generates its own
   proof.  This prevents an unauthenticated man-in-the-middle attacker
   from causing the UAC to perform private-key operations for attacker-
   generated challenges, reducing exposure to private-key extraction
   attempts that rely on side channels or fault behavior during proof
   generation.

   The existing SIP Digest parameters, including realm, username, nonce,
   uri, qop, nc, cnonce, and response, retain their existing Digest
   roles.  This document defines four new Digest parameters: server-
   pubkey, client-pubkey, client-challenge, and server-response.







Sobolyev                Expires 30 November 2026                [Page 3]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


2.  Motivation

   Traditional SIP Digest authentication is based on a username and a
   shared password or password-equivalent secret.  This model is well
   suited to human subscriber authentication and legacy provisioning
   systems, but it is a poor fit for many machine-to-machine SIP
   deployments.

   Machine-to-machine SIP authentication is often performed between
   systems, services, trunks, gateways, proxies, application servers,
   Session Border Controllers (SBCs), and other automated endpoints.
   These entities do not always naturally correspond to human usernames
   and passwords.  Password-based provisioning also creates operational
   issues: shared secrets must be generated, distributed, rotated,
   stored, and protected by both sides.  A compromise of the verifier-
   side secret database can expose password-equivalent material that can
   be used for impersonation.

   Public-key authentication is often a better fit for these
   environments.  Each endpoint can be provisioned with a private key
   and a corresponding trusted public key.  The private key does not
   need to be shared with the peer, and the public key can be
   distributed through configuration, inventory, orchestration,
   certificates, or another trust-management system.

   The mechanisms in this document use modern elliptic-curve primitives
   rather than older RSA-based public-key schemes.  X25519 and
   ristretto255 provide compact public keys and authentication material,
   efficient constant-time implementations, and simpler fixed-size
   encodings.  These properties are useful for SIP deployments where
   authentication data is carried in header fields and where endpoints
   may need to perform many authentication operations per second.

   The goal of these mechanisms is to support deployments where
   authorization is tied to possession of a configured private key
   rather than knowledge of a shared password, while preserving SIP
   Digest processing.  This model also supports deployments where a
   request is not accepted merely because it arrives from a particular
   network, IP address, interface, trunk, or transport path.  Instead,
   the receiver verifies cryptographic proof that the sender possesses
   the private key corresponding to a trusted public key, and then
   applies local authorization policy for that key, realm, endpoint,
   account, route, or service.

   SIP over TLS can provide transport confidentiality, transport
   integrity, and transport-layer peer authentication.  However, TLS
   authentication is tied to the transport connection and does not by
   itself define SIP Digest identities, Digest realm scoping, SIP



Sobolyev                Expires 30 November 2026                [Page 4]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   authorization policy, or authentication of individual SIP requests
   and entity bodies through the Digest qop model.  The mechanisms in
   this document are therefore complementary to TLS rather than
   replacements for it.

3.  Conventions and Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
   document are to be interpreted as described in BCP 14 [RFC2119]
   [RFC8174] when, and only when, they appear in all capitals, as shown
   here.

   UAC  SIP User Agent Client.

   UAS  SIP User Agent Server.

   X25519 public key  A 32-octet raw X25519 public key as specified by
      [RFC7748].

   ristretto255 public key  A 32-octet compressed ristretto255 group
      element as specified by [RFC9496].

   base64url  Base64url encoding without padding, using the URL and
      filename safe alphabet from [RFC4648] Section 5.

   digest-uri  The value of the Digest uri parameter.

   entity-body  The SIP message body used for the qop=auth-int
      calculation.

   SHA-256  The SHA-256 hash function specified by [RFC6234].

4.  Digest Parameters and Syntax

   The parameters in this section extend the Digest auth-param syntax
   used by SIP Digest authentication [RFC3261] [RFC8760].  Unless
   otherwise stated, each value is carried as a quoted string containing
   an unpadded base64url value.

   base64url-char     = ALPHA / DIGIT / "-" / "_"
   base64url-value    = 1*base64url-char
   b64q               = DQUOTE base64url-value DQUOTE

   server-pubkey      = "server-pubkey" EQUAL b64q
   client-pubkey      = "client-pubkey" EQUAL b64q
   client-challenge   = "client-challenge" EQUAL b64q
   server-response    = "server-response" EQUAL b64q



Sobolyev                Expires 30 November 2026                [Page 5]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   ALPHA, DIGIT, and DQUOTE are defined by [RFC5234].  EQUAL is
   inherited from the SIP grammar in [RFC3261].

4.1.  server-pubkey

   The server-pubkey parameter is sent by the UAS in WWW-Authenticate,
   or by a proxy in Proxy-Authenticate.

   For X25519-HKDF-SHA256 and X25519-HMAC-SHA256, it contains the raw
   32-octet X25519 public key of the authenticating server.  For R25519-
   SCHNORR-SHA256, it contains the 32-octet ristretto255 public key of
   the authenticating server.

   A UAC receiving this parameter MUST verify that the decoded public
   key is trusted for the challenged SIP realm, peer, route, outbound
   proxy, or configured authentication domain before generating an
   authorization response.

4.2.  client-pubkey

   The client-pubkey parameter is sent by the UAC in Authorization or
   Proxy-Authorization.

   For X25519-HKDF-SHA256 and X25519-HMAC-SHA256, it contains the raw
   32-octet X25519 public key of the authenticating client.  For R25519-
   SCHNORR-SHA256, it contains the 32-octet ristretto255 public key
   whose corresponding private scalar is proven by the UAC.

   A UAS receiving this parameter MUST verify that the decoded public
   key is trusted for the claimed username, if present, and realm.  If
   username is absent, the UAS MUST verify that client-pubkey is trusted
   for the realm and for the applicable account, subscriber, endpoint,
   authorization identity, or other local authorization record.

4.3.  client-challenge

   The client-challenge parameter is sent by the UAC in an initial
   Authorization or Proxy-Authorization header when requesting an
   authenticated server challenge.  It contains at least 128 bits of
   client-generated randomness.

   The parameter is used by R25519-SCHNORR-SHA256 to allow the UAS to
   prove possession of the private scalar corresponding to server-pubkey
   in the 401 or 407 challenge response.  The UAS MUST NOT echo client-
   challenge in WWW-Authenticate or Proxy-Authenticate.






Sobolyev                Expires 30 November 2026                [Page 6]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   The UAC MUST verify server-response using the locally remembered
   client-challenge value that it generated and sent.  The UAC MUST NOT
   use any reflected or received client-challenge value from a response
   header when verifying server-response.

4.4.  server-response

   The server-response parameter is sent by the UAS in WWW-Authenticate,
   or by a proxy in Proxy-Authenticate, when responding to a request
   that contained client-challenge.

   The value is base64url(R || s), where R is a compressed ristretto255
   commitment of 32 octets and s is a canonical scalar modulo the
   ristretto255 group order, encoded as 32 octets.  The decoded value is
   therefore exactly 64 octets.

5.  Transcript Encoding

   All cryptographic transcripts defined by this document use the
   following deterministic encoding to avoid ambiguity between adjacent
   SIP and Digest fields.

   Transcript(label, field-list) is the octet string formed by
   concatenating the US-ASCII label, a line feed (%x0A), and then, for
   each field in order:

   1.  the US-ASCII field name,

   2.  a colon (%x3A),

   3.  the decimal octet length of the field value encoded in US-ASCII
       without leading zeroes,

   4.  another colon,

   5.  the field value octets, and

   6.  a line feed.

   Unless otherwise stated, SIP and Digest string fields are encoded
   exactly as their field values appear after Digest quoted-string
   unescaping.  Binary fields, including public keys, shared secrets,
   commitments, scalars, and hash outputs, are encoded as their raw
   octets when they are transcript fields.  The final line feed is part
   of the transcript.






Sobolyev                Expires 30 November 2026                [Page 7]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   For qop=auth, the body-hash transcript field is the zero-length
   value.  For qop=auth-int, it is the raw 32-octet SHA-256 digest of
   the entity body.

6.  Common Digest Fields

   The Digest fields realm, username, nonce, uri, qop, nc, cnonce, and
   response retain their usual meanings in SIP Digest authentication,
   except as explicitly stated in this section.  For all algorithms in
   this document, realm is REQUIRED and qop=auth and qop=auth-int are
   supported.

   For the algorithms defined by this document, username is OPTIONAL.
   For all calculations and transcripts defined by this document, an
   absent username is equivalent to an explicitly empty username.  All
   formulas that reference username use the received username value if
   present, or a zero-length string if absent.

   If username is present, it is an identity hint.  The verifier MAY use
   it to select an account, subscriber, endpoint, or authorization
   record.  The verifier MUST still verify that client-pubkey is trusted
   for the claimed username and realm.  If username is absent, the
   verifier MUST identify the peer by client-pubkey and realm using
   local policy.

   When qop=auth-int is used, the authentication calculation includes
   the entity-body hash.  For SIP INVITE requests carrying Session
   Description Protocol (SDP), this provides integrity protection for
   the SDP body against attackers that cannot produce the required
   authentication response.

   The response value is algorithm-specific.  The X25519-HKDF-SHA256 and
   X25519-HMAC-SHA256 algorithms encode response as lowercase
   hexadecimal.  The R25519-SCHNORR-SHA256 algorithm uses a different
   format: response is an unpadded base64url encoding of the 64-octet
   Schnorr proof R_c || s_c.

7.  Algorithm: X25519-HKDF-SHA256

7.1.  Challenge

   The UAS sends a Digest challenge with algorithm=X25519-HKDF-SHA256
   and server-pubkey.








Sobolyev                Expires 30 November 2026                [Page 8]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   WWW-Authenticate: Digest
       realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       qop="auth,auth-int",
       server-pubkey="xRbeh9_DZBrONNFs7P8rhZhcLlXSw79RU5frhaOvIZc"

7.2.  Authorization Response

   The UAC sends a Digest authorization response with client-pubkey.
   The username parameter MAY be omitted.

   Example with username present:

   Authorization: Digest
       username="alice",
       realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="fPEDas5tsJgGPG_QMPVECsTySsC0TFGHRVSNcWSmABQ",
       response="281847efc4a3739d638de9f729fb6b5565bb2f2a006f1719"

   Example with username absent:

   Authorization: Digest
       realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="zLhVVAHkZJ8oNU-v2DKauUB_TvWBn1dpcBFtQL6kd6s",
       response="fb2e80bda9f83361e995f1c7662b5cc32ee259f3c4ea9d66"

7.3.  Shared Secret Calculation

   The UAC computes Z = X25519(client-private-key, server-pubkey).  The
   UAS computes Z = X25519(server-private-key, client-pubkey).  Both
   sides MUST reject the exchange if the computed X25519 shared secret
   is the all-zero value.

   The Digest response key K is derived with HKDF-SHA256 [RFC5869]:




Sobolyev                Expires 30 November 2026                [Page 9]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   salt = Transcript("SIP-Digest-X25519-HKDF-SHA256-salt-v1",
                     nonce, cnonce)

   info = Transcript("SIP-Digest-X25519-HKDF-SHA256-info-v1",
                     algorithm, username, realm, nonce, cnonce,
                     server-pubkey, client-pubkey)

   K = HKDF-SHA256(IKM = Z, salt = salt, info = info, L = 32)

7.4.  Response Calculation

   The response value is computed as follows:

   body-hash = ""                  ; for qop=auth
   body-hash = SHA-256(entity-body) ; for qop=auth-int

   HA1 = SHA-256(Transcript(
             "SIP-Digest-X25519-HKDF-SHA256-HA1-v1",
             username, realm, K))

   HA2 = SHA-256(Transcript(
             "SIP-Digest-X25519-HKDF-SHA256-HA2-v1",
             method, digest-uri, qop, body-hash))

   response = SHA-256(Transcript(
             "SIP-Digest-X25519-HKDF-SHA256-response-v1",
             HA1, nonce, nc, cnonce, qop, HA2))

   The response value is encoded as lowercase hexadecimal SHA-256
   output.

8.  Algorithm: X25519-HMAC-SHA256

   The X25519-HMAC-SHA256 algorithm uses the same server-pubkey and
   client-pubkey parameters as X25519-HKDF-SHA256, but computes the
   final response as an HMAC [RFC2104] rather than as a Digest-style
   hash chain.

8.1.  Challenge

   The UAS sends a Digest challenge with algorithm=X25519-HMAC-SHA256
   and server-pubkey.









Sobolyev                Expires 30 November 2026               [Page 10]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   WWW-Authenticate: Digest
       realm="sip.example.net",
       algorithm=X25519-HMAC-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       qop="auth,auth-int",
       server-pubkey="bzeK9qEcpcMStQYlqQbVs5NfjMMu76AlsKV587PvlT8"

8.2.  Authorization Response

   The UAC sends a Digest authorization response with client-pubkey.
   The username parameter MAY be omitted.

   Example with username present:

   Authorization: Digest
       username="alice",
       realm="sip.example.net",
       algorithm=X25519-HMAC-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="hDX3Ky19NCnnzATsdgvdu5BvPqwGdOOP1koEUWU6gZ4",
       response="3401ac99fa30dacdeeb245749639dcd46c504611df2398dd"

   Example with username absent:

   Authorization: Digest
       realm="sip.example.net",
       algorithm=X25519-HMAC-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="dywz9UEYmTmzGXuNrfSZGw1maX0vGJ3i4kMPaHmRyzo",
       response="14ec53f746359ba4d64ff8cf8d5667cbe64b14c9b50c4dd4"

8.3.  Shared Secret Calculation

   The UAC computes Z = X25519(client-private-key, server-pubkey).  The
   UAS computes Z = X25519(server-private-key, client-pubkey).  Both
   sides MUST reject the exchange if the computed X25519 shared secret
   is the all-zero value.






Sobolyev                Expires 30 November 2026               [Page 11]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   K = SHA-256(Transcript(
           "SIP-Digest-X25519-HMAC-SHA256-key-v1",
           Z, algorithm, username, realm, nonce, cnonce,
           server-pubkey, client-pubkey))

8.4.  HMAC Transcript

   body-hash = ""                  ; for qop=auth
   body-hash = SHA-256(entity-body) ; for qop=auth-int

   transcript = Transcript(
           "SIP-Digest-X25519-HMAC-SHA256-response-v1",
           username, realm, nonce, nc, cnonce, qop,
           method, digest-uri, body-hash, server-pubkey, client-pubkey)

   response = HMAC-SHA256(K, transcript)

   The response value is encoded as lowercase hexadecimal HMAC-SHA256
   output.

9.  Algorithm: R25519-SCHNORR-SHA256

   The R25519-SCHNORR-SHA256 algorithm defines a Schnorr-style Fiat-
   Shamir non-interactive proof of knowledge over the ristretto255
   group.  The UAC proves knowledge of a scalar x_c corresponding to
   client-pubkey = x_c * G, where G is the canonical ristretto255 base
   point.

9.1.  Optional Authenticated Server Challenge Request

   A UAC MAY request an authenticated server challenge by including
   client-challenge in an initial request.

   INVITE sip:bob@example.net SIP/2.0
   Authorization: Digest
       algorithm=R25519-SCHNORR-SHA256,
       client-challenge="0Xc7ag8QRtRWlamLDDozsA"

   This header does not authenticate the UAC.  It only supplies
   freshness for an authenticated server challenge.  A UAC that sends
   client-challenge MUST remember the value locally until it receives
   and verifies the corresponding WWW-Authenticate or Proxy-Authenticate
   challenge, or until the transaction is abandoned.








Sobolyev                Expires 30 November 2026               [Page 12]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


9.2.  Challenge

   The UAS sends a Digest challenge with algorithm=R25519-SCHNORR-SHA256
   and server-pubkey.  If the request contained a valid client-
   challenge, the UAS MAY include server-response.

   WWW-Authenticate: Digest
       realm="sip.example.net",
       algorithm=R25519-SCHNORR-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       qop="auth,auth-int",
       server-pubkey="xBiXzi82PKyiSqcRBXJauiNECbQDQZfzt-RRwzsKAXs",
       server-response="neTvyoW2SLh32ob-UTteu_ragDBe2Ub3wqhm969gjlw"

9.3.  Authenticated Server Challenge Proof

   When server-response is present, it proves possession of the private
   scalar corresponding to server-pubkey.  The UAS has private scalar
   x_s and public key A_s = x_s * G, where A_s is server-pubkey.

   T_srv_chal = Transcript(
       "SIP-Digest-R25519-SCHNORR-SHA256-ServerChallenge-v1",
       algorithm, method, digest-uri, realm, nonce, qop-list,
       server-pubkey, client-challenge)

   R_s = r_s * G
   c_s = SHA-256(Transcript(
             "SIP-Digest-R25519-SCHNORR-SHA256-ServerChallenge-c-v1",
             T_srv_chal, R_s)) mod L
   s_s = r_s + c_s * x_s mod L

   server-response = base64url(R_s || s_s)

   r_s is a fresh random scalar and L is the ristretto255 group order.
   The UAC verifies by recomputing the transcript and checking s_s * G
   == R_s + c_s * A_s.

   The UAC MUST reject the challenge if server-response is required by
   local policy and is absent, malformed, invalid, not bound to the
   locally remembered client-challenge, or not valid for the received
   server-pubkey.










Sobolyev                Expires 30 November 2026               [Page 13]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


9.4.  Authorization Proof

   The UAC sends a Digest authorization response with client-pubkey.
   The username parameter MAY be omitted.  The response parameter
   contains base64url(R_c || s_c), where R_c is a compressed
   ristretto255 commitment and s_c is a canonical scalar modulo the
   group order.  This differs from the hexadecimal Digest response
   values used by the X25519 algorithms.  The decoded value is exactly
   64 octets.

   A_c = x_c * G
   R_c = r_c * G

   body-hash = ""                  ; for qop=auth
   body-hash = SHA-256(entity-body) ; for qop=auth-int

   T_uac = Transcript(
       "SIP-Digest-R25519-SCHNORR-SHA256-UAC-v1",
       algorithm, username, realm, nonce, nc, cnonce, qop,
       method, digest-uri, body-hash, server-pubkey, client-pubkey)

   c_c = SHA-256(Transcript(
             "SIP-Digest-R25519-SCHNORR-SHA256-UAC-c-v1",
             T_uac, R_c)) mod L
   s_c = r_c + c_c * x_c mod L

   response = base64url(R_c || s_c)

   The UAS decodes A_c from client-pubkey, reconstructs T_uac from the
   received request and Digest parameters, and accepts only if s_c * G
   == R_c + c_c * A_c.  The UAS MUST reject malformed ristretto255
   encodings, non-canonical scalars, invalid proof lengths, and proofs
   that are not valid for the exact received transcript.

   A proof generated for one method, URI, nonce, cnonce, nonce-count,
   qop value, body, realm, server public key, client public key, or
   username value MUST NOT be accepted for another.

10.  Verification Rules

   A receiver MUST reject authentication if any of the following are
   true:

   *  server-pubkey is absent from the challenge;

   *  client-pubkey is absent from the authorization response;

   *  realm is absent from the challenge or authorization response;



Sobolyev                Expires 30 November 2026               [Page 14]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   *  a public key is malformed for the selected algorithm;

   *  the peer public key is not trusted for the claimed identity or
      realm;

   *  nonce is expired, unknown, malformed, or already consumed;

   *  nc does not increase monotonically for the nonce and client
      identity pair;

   *  cnonce is absent when qop is present;

   *  qop is unsupported;

   *  response is malformed; or

   *  response does not match or verify against the locally computed
      value.

   For R25519-SCHNORR-SHA256, a receiver MUST also reject authentication
   if server-response is malformed when present, is absent when required
   by local policy, or does not verify against the locally remembered
   client-challenge.

   A UAS MUST NOT authenticate a UAC merely because client-pubkey is
   present.  The client-pubkey value MUST be bound to a trusted
   identity, such as the username if present, configured endpoint,
   account, subscriber, realm, or equivalent local authorization record.

   A UAC MUST NOT answer a challenge merely because server-pubkey is
   present.  The server-pubkey value MUST be present in the UAC's
   trusted key list for the challenged peer, realm, outbound proxy, or
   service domain.

   Implementations MUST reject algorithm identifiers other than those
   explicitly defined by this document or locally configured for this
   mechanism.

11.  Replay Protection

   The UAS MUST generate nonces with sufficient entropy and
   unpredictability.  The UAS MUST reject replayed tuples of client-
   pubkey, nonce, nc, and cnonce.  If username is present, the UAS MAY
   also include username in the replay cache key.  The UAS SHOULD expire
   nonces after a short interval and SHOULD bind nonces to the
   challenged realm, selected algorithm, and server-pubkey.





Sobolyev                Expires 30 November 2026               [Page 15]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   The UAC SHOULD generate a fresh client-challenge for each initial
   authenticated challenge request.  The UAC MUST NOT accept a server-
   response generated for a different client-challenge.

12.  Body Integrity

   When qop=auth-int is used, the entity-body hash is included in the
   authentication calculation.  For SIP requests carrying SDP, this
   protects the SDP body against modification by an attacker that does
   not know the X25519-derived authentication secret or cannot generate
   the required ristretto255 Schnorr proof.

   If intermediaries are expected to modify the SDP body, qop=auth-int
   can fail unless the modification happens before the UAC computes the
   authorization response or unless the deployment explicitly permits
   such behavior.

13.  Examples

13.1.  Initial Request Asking for Authenticated Server Challenge

   INVITE sip:bob@example.net SIP/2.0
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314159 INVITE
   Authorization: Digest algorithm=R25519-SCHNORR-SHA256,
       client-challenge="QG7xYpk5XlVz9hHMKx3uRg"
   Content-Length: 0

13.2.  Authenticated R25519-SCHNORR-SHA256 Challenge

   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>;tag=a6c85cf
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314159 INVITE
   WWW-Authenticate: Digest realm="sip.example.net",
       algorithm=R25519-SCHNORR-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       qop="auth,auth-int",
       server-pubkey="V8nM6R1l7Pp4sLdbZSyGx6Fv5F1LxPvV9gzLg4YhV2I",
       server-response="Jvx3L4ZPTVq43cacYBONePT4nInA-F8FPqL1mv7ORC0"
   Content-Length: 0





Sobolyev                Expires 30 November 2026               [Page 16]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


13.3.  R25519-SCHNORR-SHA256 Authorization with Username

   INVITE sip:bob@example.net SIP/2.0
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314160 INVITE
   Contact: <sip:alice@client.example.org>
   Authorization: Digest username="alice",
       realm="sip.example.net",
       algorithm=R25519-SCHNORR-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="LKz2bq0TLeHqkCJ2m6v9MGWQp9WnZtDZ9pYyHk4IoX0",
       response="mU7Wgqm2wHIAk993xXo6OXKMQBNtgl-mFJQ_-Rgo8oI"
   Content-Type: application/sdp
   Content-Length: ...

13.4.  R25519-SCHNORR-SHA256 Authorization without Username

   INVITE sip:bob@example.net SIP/2.0
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314160 INVITE
   Contact: <sip:alice@client.example.org>
   Authorization: Digest
       realm="sip.example.net",
       algorithm=R25519-SCHNORR-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="a0t5YmU8Ppgp0zLGgwsVXnxViPImkjyyzWTDj5wfmxE",
       response="bde_KoYDFV3SYJa55WppUdlgLjhgM3vqT5U7qa6YR_o"
   Content-Type: application/sdp
   Content-Length: ...

13.5.  X25519-HKDF-SHA256 Challenge






Sobolyev                Expires 30 November 2026               [Page 17]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>;tag=a6c85cf
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314159 INVITE
   WWW-Authenticate: Digest realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       qop="auth,auth-int",
       server-pubkey="V8nM6R1l7Pp4sLdbZSyGx6Fv5F1LxPvV9gzLg4YhV2I"
   Content-Length: 0

13.6.  X25519-HKDF-SHA256 Authorization with Username

   INVITE sip:bob@example.net SIP/2.0
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314160 INVITE
   Contact: <sip:alice@client.example.org>
   Authorization: Digest username="alice",
       realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="LKz2bq0TLeHqkCJ2m6v9MGWQp9WnZtDZ9pYyHk4IoX0",
       response="92eab8507440bf720bfffdffcdab35c785ddee69d419db58"
   Content-Type: application/sdp
   Content-Length: ...

13.7.  X25519-HKDF-SHA256 Authorization without Username















Sobolyev                Expires 30 November 2026               [Page 18]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   INVITE sip:bob@example.net SIP/2.0
   Via: SIP/2.0/TLS client.example.org;branch=z9hG4bK776asdhds
   From: <sip:alice@example.org>;tag=1928301774
   To: <sip:bob@example.net>
   Call-ID: a84b4c76e66710@example.org
   CSeq: 314160 INVITE
   Contact: <sip:alice@client.example.org>
   Authorization: Digest
       realm="sip.example.net",
       algorithm=X25519-HKDF-SHA256,
       nonce="NQ7x0vR3VnP0aK9fW6tDHA",
       uri="sip:bob@example.net",
       qop=auth-int,
       nc=00000001,
       cnonce="q1w2e3r4t5y6",
       client-pubkey="q6wi4GXRx1poYAVvqcp7nmC4FU0MDxnvooatixWp1mY",
       response="d857749505ba1cc5262d945bfd793d7988f6a0d675eab113"
   Content-Type: application/sdp
   Content-Length: ...

14.  IANA Considerations

   This document requests registration of the following Digest algorithm
   tokens in the applicable Digest algorithm registry:

   *  X25519-HKDF-SHA256

   *  X25519-HMAC-SHA256

   *  R25519-SCHNORR-SHA256

   The following Digest authentication parameters are also defined by
   this document: server-pubkey, client-pubkey, client-challenge, and
   server-response.

15.  Implementation Notes

   Implementations SHOULD use well-reviewed cryptographic libraries for
   X25519, HKDF-SHA256, HMAC-SHA256, SHA-256, and ristretto255.
   Implementations SHOULD avoid accepting algorithm aliases.

   Implementations SHOULD domain-separate every proof or MAC input
   exactly as specified.

   Implementations SHOULD log authentication failures without logging
   private keys, shared secrets, raw proof scalars, derived keys, or
   complete authentication transcripts.




Sobolyev                Expires 30 November 2026               [Page 19]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   Implementations SHOULD treat server-pubkey and client-pubkey as
   identity-bearing material and apply local authorization policy before
   accepting a request.

   Implementations need to account for generic Digest parsers that
   assume username is always present.  Implementations of this
   specification MUST support the absence of username for the algorithms
   defined here.

16.  Security Considerations

   This mechanism prevents impersonation only when both sides have
   securely provisioned peer public keys, bind those keys to the
   applicable realm and authorization identity, and enforce the replay
   protections required by this document.  X25519 by itself is not
   authentication.  Authentication is achieved only by deriving a secret
   from a trusted peer public key and proving possession of the
   corresponding private key through the Digest response.

   For X25519-HKDF-SHA256 and X25519-HMAC-SHA256, the UAC trusts the UAS
   X25519 public key and the UAS trusts the UAC X25519 public key.  For
   R25519-SCHNORR-SHA256, the UAS trusts the UAC ristretto255 public
   key, and the UAC trusts the UAS ristretto255 public key before
   answering the challenge.  The server-response parameter provides
   authenticated server challenges when required by local policy.

   The ristretto255 Schnorr algorithm authenticates the UAC by proving
   knowledge of the private scalar corresponding to client-pubkey, bound
   to the SIP Digest transcript.  The server-response parameter
   authenticates the server challenge by proving knowledge of the
   private scalar corresponding to server-pubkey, bound to a UAC-
   generated client-challenge.

   Nonce freshness, nonce-count validation, client nonce validation, and
   replay-cache enforcement are part of the security of this mechanism.
   An implementation that accepts replayed Digest responses can
   authenticate a stale request even when the cryptographic proof or MAC
   is otherwise valid.

   These algorithms authenticate SIP Digest exchanges and, when
   qop=auth-int is used, provide integrity protection for the
   authenticated SIP entity body.  They do not establish a confidential
   transport channel, protect SIP metadata, or provide media security.
   Deployments requiring confidential signaling, SIP metadata
   protection, transport-layer peer authentication, or media security
   SHOULD use SIP over TLS and appropriate media-security mechanisms.





Sobolyev                Expires 30 November 2026               [Page 20]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   Compromise of a provisioned private key enables impersonation for the
   identities and realms authorized for the corresponding public key.
   Deployments need operational procedures for protecting, rotating, and
   revoking keys according to local policy.

   Schnorr nonces MUST be generated with high-quality randomness or by a
   deterministic nonce generation construction with equivalent security.
   Reusing a Schnorr nonce with the same private scalar can reveal the
   private scalar.

   Implementations MUST use constant-time comparison when checking MAC
   or hash responses and SHOULD use constant-time scalar and group
   operations where provided by the cryptographic library.

17.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, July 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.






Sobolyev                Expires 30 November 2026               [Page 21]

Internet-Draft    SIP Digest Public-Key Authentication          May 2026


   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8760]  Shekh-Yusef, R., "The Session Initiation Protocol (SIP)
              Digest Access Authentication Scheme", RFC 8760,
              DOI 10.17487/RFC8760, March 2020,
              <https://www.rfc-editor.org/info/rfc8760>.

   [RFC9496]  de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I.,
              Tankersley, G., and F. Valsorda, "The ristretto255 and
              decaf448 Groups", RFC 9496, DOI 10.17487/RFC9496, December
              2023, <https://www.rfc-editor.org/info/rfc9496>.

Author's Address

   Maksym Sobolyev
   Sippy Software, Inc.
   Email: sobomax@sippysoft.com























Sobolyev                Expires 30 November 2026               [Page 22]
