Skip to content

Commit f9f94ff

Browse files
wilawwilaw
authored
Merge pull request #26 from moq-wg/snk-sec
Add support for DPoP Claims in CAT for MOQT
2 parents 57c2b33 + d05b6c5 commit f9f94ff

File tree

1 file changed

+307
-4
lines changed

1 file changed

+307
-4
lines changed

‎draft-law-moq-cat4moqt.md‎

Lines changed: 307 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -55,12 +55,19 @@ author:
5555
normative:
5656
MoQTransport: I-D.draft-ietf-moq-transport-10
5757
Composite: I-D.draft-lemmons-cose-composite-claims-01
58+
MoQTransport: I-D.draft-ietf-moq-transport-14
5859
BASE64: RFC4648
5960
CAT:
6061
title: "CTA 5007-B Common Access Token"
6162
date: April 2025
6263
target: https://shop.cta.tech/products/cta-5007
63-
64+
DPoP: RFC9449
65+
DPOP-PROOF:
66+
title: "Application-Agnostic Demonstrating Proof-of-Possession"
67+
author:
68+
name: "S. Nandakumar"
69+
date: December 2024
70+
target: https://www.ietf.org/archive/id/draft-nandakumar-oauth-dpop-proof-00.txt
6471
informative:
6572

6673

@@ -103,7 +110,8 @@ This draft defines version 1 of this specification.
103110
* As an alternative to this workflow, the distribution service may vend multiple tokens to the client. The
104111
client may use one of those tokens to establish the initial conneciton and others to authenticate its actions.
105112

106-
~~~ascii
113+
~~~ascii
114+
107115
End User Distribution Service MOQT Relay
108116
| | |
109117
| | 0. Share secrets |
@@ -137,7 +145,7 @@ This draft defines version 1 of this specification.
137145
| | (if moqt-reval set, |
138146
| | repeats at interval |
139147
| | e.g., every 5 min) |
140-
~~~
148+
~~~
141149

142150
# Token format
143151

@@ -370,6 +378,301 @@ claims, the token is not well-formed.
370378
The claim key for this claim is TBD_MOQT_REVAL and the claim value is a number.
371379
Recipients MUST support this claim. This claim is OPTIONAL for issuers.
372380

381+
# DPoP Integration with CAT for MOQT
382+
383+
This section defines the use of CAT's Demonstrating Proof of Possession (DPoP)
384+
claims {{DPoP}} to enhance security in MOQT environments. This approach
385+
leverages the CAT token's "cnf" (confirmation) claim with JWK Thumbprint
386+
binding and the "catdpop" (CAT DPoP Settings) claim to provide
387+
proof-of-possession capabilities that prevent token theft and replay
388+
attacks in MOQT systems.
389+
390+
## CAT DPoP Claims for MOQT
391+
392+
This proposal extends the CAT authentication model by binding tokens to
393+
client cryptographic key pairs. To enable sender-constrained token usage,
394+
the CAT tokens include DPoP-related claims as defined {{CAT}} Section 4.8,
395+
ensuring that only the legitimate token holder can use the token for MOQT
396+
operations.
397+
398+
### Confirmation (cnf) Claim with JWK Thumbprint
399+
400+
DPoP binding is accomplished by providing the "cnf" claim with the "jkt"
401+
(JWK Thumbprint) confirmation method.
402+
403+
Below is an exmaple showing jkt token binding.
404+
405+
~~~~
406+
407+
{
408+
/ cnf /
409+
8: {
410+
/ jkt /
411+
3: <32-byte JWK SHA-256 Thumbprint>
412+
},
413+
/ moqt /
414+
TBD_MOQT: [
415+
[
416+
[2, 3, 6, 7], / ANNOUNCE, SUBSCRIBE_NAMESPACE, PUBLISH, FETCH /
417+
{"exact": "cdn.example.com"},
418+
{"prefix": "/sports/"}
419+
]
420+
],
421+
/ catdpop /
422+
321: {
423+
0: 300, / 5-minute window /
424+
1: 1 / Honor jti for replay protection /
425+
},
426+
/ exp /
427+
4: 1750000000
428+
}
429+
~~~~
430+
431+
Implementation Requirements:
432+
433+
- Relay Validation: MOQT relays MUST verify that DPoP proofs are signed with
434+
the private key corresponding to the "jkt" value
435+
- Proof Binding: Relays MUST reject requests where DPoP proof validation or
436+
key binding fails
437+
- Processing Semantics: Relays MUST process DPoP proofs as Protected Resource
438+
Access requests per {{DPoP}} Section 7
439+
440+
441+
### DPoP Extension with Application-Agnostic Proof Framework
442+
443+
This section defines the use of DPoP with an application-agnostic proof
444+
framework as specified in {{DPOP-PROOF}}, which
445+
extends the traditional HTTP-centric DPoP model to support arbitrary
446+
protocols including MOQT. This approach replaces HTTP-specific claims
447+
with a flexible authorization context structure that can accommodate
448+
protocol-specific command representations.
449+
450+
The DPoP proof JWT follows the structure defined in Section 4 of
451+
{{DPOP-PROOF}} with the following required claims:
452+
453+
JWT Header:
454+
455+
- "typ": "dpop-proof+jwt"
456+
- "alg": Asymmetric signature algorithm identifier
457+
- "jwk": Public key for verification
458+
459+
JWT Payload:
460+
461+
- "jti": Unique identifier for the JWT
462+
- "iat": Issued-at time
463+
- "actx": Authorization Context object
464+
465+
For MOQT operations, the Authorization Context ("actx") object contains:
466+
467+
- "type": "moqt" (registered identifier for MOQT protocol)
468+
- "action": MOQT action identifier
469+
- "tns": Track namespace (required)
470+
- "tn": Track name (required)
471+
- "resource": MOQT resource identifier (optional)
472+
473+
When the optional "resource" parameter is included, it MUST be consistent with the
474+
"tns" and "tn" parameters. The resource URI should follow the format
475+
`moqt://<relay-endpoint>?tns=<namespace>&tn=<track>` where the tns and tn query
476+
parameters match the respective "tns" and "tn" fields in the Authorization Context.
477+
478+
Example DPoP proof for MOQT ANNOUNCE operation:
479+
480+
~~~~~~~~~~~~~~~
481+
{
482+
"typ": "dpop-proof+jwt",
483+
"alg": "ES256",
484+
"jwk": { ... }
485+
}
486+
.
487+
{
488+
"jti": "unique-request-id",
489+
"iat": 1705123456,
490+
"actx": {
491+
"type": "moqt",
492+
"action": "ANNOUNCE",
493+
"tns": "sports",
494+
"tn": "live-feed"
495+
}
496+
}
497+
~~~~~~~~~~~~~~~
498+
499+
MOQT action mapping for Authorization Context:
500+
501+
|----------------------|-------------|
502+
| MOQT Action | actx.action |
503+
|----------------------|-------------|
504+
| CLIENT_SETUP | SETUP |
505+
| SERVER_SETUP | SETUP |
506+
| ANNOUNCE | ANNOUNCE |
507+
| SUBSCRIBE_NAMESPACE | SUB_NS |
508+
| SUBSCRIBE | SUBSCRIBE |
509+
| PUBLISH | PUBLISH |
510+
| FETCH | FETCH |
511+
|----------------------|-------------|
512+
513+
Relays supporting this application-agnostic DPoP framework MUST:
514+
515+
- Validate DPoP proofs according to {{DPOP-PROOF}}
516+
- Verify that the "actx.type" is "moqt" for MOQT operations
517+
- Validate that the "actx.action" matches the requested MOQT action
518+
- Verify that the "actx.tns" corresponds to the target track namespace
519+
- Verify that the "actx.tn" corresponds to the target track name
520+
- If present, verify the "actx.resource" is consistent with "tns" and "tn"
521+
- Reject requests where Authorization Context validation fails
522+
523+
### MOQT Resource URI Construction
524+
525+
The Authorization Context "resource" field should specify track namespace (tns) and track name (tn) parameters for MOQT resources:
526+
527+
- Connection setup: `moqt://<relay-endpoint>`
528+
- Namespace operations: `moqt://<relay-endpoint>?tns=<namespace>`
529+
- Track operations: `moqt://<relay-endpoint>?tns=<namespace>&tn=<track>`
530+
531+
## DPoP Proof Process and Token Binding Flow
532+
533+
The following process illustrates how DPoP proof provision results in CAT
534+
token binding and subsequent MOQT relay validation:
535+
536+
### Phase 1: Token Acquisition with DPoP Binding
537+
538+
~~~~
539+
┌──────────────┐ ┌─────────────────────┐ ┌──────┐
540+
│MOQT Client │ │Authorization Server │ │MOQT │
541+
│ │ │ │ │Relay │
542+
└──────┬───────┘ └──────────┬──────────┘ └──────┘
543+
│ │ │
544+
│ (1) Generate Key Pair │ │
545+
│ EC P-256/RSA │ │
546+
│ private_key, public_key │ │
547+
│ │ │
548+
│ (2) Authentication Request │ │
549+
│ + User Credentials │ │
550+
│ + Public Key (JWK format) │ │
551+
├──────────────────────────────────►│ │
552+
│ │ │
553+
│ │ (3) User Authentication │
554+
│ │ & Authorization │
555+
│ │ │
556+
│ │ (4) Generate CAT Token: │
557+
│ │ • "cnf" claim with │
558+
│ │ "jkt": SHA256(public_key)│
559+
│ │ • "catdpop" processing │
560+
│ │ settings │
561+
│ │ • "moqt" action scope │
562+
│ │ • Sign with shared secret │
563+
│ │ │
564+
│ (5) CAT Token Response │ │
565+
│ + Bound CAT Token │ │
566+
│ + Relay Endpoint URL │ │
567+
|◄──────────────────────────────────┤ │
568+
│ │ │
569+
~~~~
570+
571+
Steps 1-5 Detail:
572+
573+
1. Client Key Generation: The MOQT client generates an asymmetric key pair
574+
(typically EC P-256) for DPoP operations
575+
2. Authentication with Public Key: Client authenticates with the authorization
576+
server, providing user credentials and the public key
577+
3. User Authentication: Authorization server validates user identity and
578+
permissions
579+
1. CAT Token Generation: Server creates a CAT token containing:
580+
- "cnf" claim: JWK Thumbprint ("jkt") of the client's public key
581+
(32-byte SHA-256 hash)
582+
- "catdpop" claim: DPoP processing settings (window, jti handling,
583+
critical settings)
584+
- "moqt" claim: Authorized MOQT actions and scope restrictions
585+
2. Token Delivery: Server provides the bound CAT token and relay endpoint
586+
information to the client
587+
588+
### Phase 2: MOQT Operations with DPoP Proof Validation
589+
590+
~~~~
591+
┌──────────────┐ ┌─────────────────────┐ ┌───────┐
592+
│MOQT Client │ │Authorization Server │ │MOQT │
593+
│ │ │ │ │Relay │
594+
└──────┬───────┘ └──────────┬──────────┘ └──────┬┘
595+
│ │ │
596+
│ │ │
597+
│ (6) For each MOQT action: │ │
598+
│ Create fresh DPoP proof JWT │ │
599+
│ • Header: typ="dpop-proof+jwt"│ │
600+
│ • alg, jwk │ │
601+
│ • Claims: jti, iat, actx │ │
602+
│ • Sign with private_key │ │
603+
│ │ │
604+
│ (7) MOQT Request │ │
605+
│ + CAT Token │ │
606+
│ + Fresh DPoP Proof │ │
607+
│ (CLIENT_SETUP, ANNOUNCE, │ │
608+
│ SUBSCRIBE, PUBLISH, FETCH) │ │
609+
├─────────────────────────────────────────────────────────────────────►│
610+
│ │ │
611+
│ │ (8)│
612+
│ │ CAT Validation: │
613+
│ │ • Verify token │
614+
│ │ signature │
615+
│ │ • Validate claims│
616+
│ │ including exp, |
617+
| | scope │
618+
│ │ │
619+
│ │ (9)│
620+
│ │ DPoP Validation: │
621+
│ │ • Extract "jkt" │
622+
│ │ from token │
623+
│ │ • Verify DPoP │
624+
│ │ JWT signature │
625+
│ │ • Validate key │
626+
│ │ binding │
627+
│ │ • Check │
628+
│ │ freshness │
629+
│ │ │
630+
│ │ (10)│
631+
│ │ Action Authorization│
632+
│ │ • Match action │
633+
│ │ to token scope│
634+
│ │ • Check ns/track│
635+
│ │ permissions │
636+
│ │ │
637+
│ (11) Response │ │
638+
│ Success/Error │ │
639+
◄─────────────────────────────────────────────────────────────────────┤
640+
│ │ │
641+
~~~~
642+
643+
Steps 6-11 Detail:
644+
645+
6. DPoP Proof Creation: For each MOQT action, the client creates a fresh
646+
DPoP proof JWT with:
647+
- Header: `typ: "dpop-proof+jwt"`, `alg`, `jwk` (public key)
648+
- Claims: `jti` (unique ID), `iat` (timestamp), `actx`
649+
(Authorization Context with type, action, tns, tn)
650+
651+
1. MOQT Request: Client sends MOQT action with both CAT token and fresh DPoP
652+
proof
653+
654+
2. CAT Token Validation: Relay validates:
655+
- Token signature using shared secret with authorization server
656+
- Token expiration time
657+
- "moqt" claim scope for requested action
658+
659+
3. DPoP Proof Validation: Relay performs:
660+
661+
- Extract "jkt" (JWK Thumbprint) from CAT token's "cnf" claim
662+
- Verify DPoP JWT signature using embedded public key
663+
- Confirm that SHA-256 hash of DPoP public key matches "jkt" value
664+
- Check proof freshness within "catdpop" window settings
665+
- Process replay protection based on "jti" settings
666+
- Validate Authorization Context ("actx") according to {{DPOP-PROOF}}
667+
- Verify "actx.type" is "moqt"
668+
- Validate "actx.action" matches the requested MOQT action
669+
- Verify "actx.tns" and "actx.tn" correspond to target resources
670+
671+
4. Action Authorization: Relay validates the specific MOQT action against
672+
token scope and namespace/track permissions
673+
674+
5. Response: Relay responds with success or appropriate error information
675+
373676
# Adding a token to a URL
374677

375678
Any time an application wishes to add a CAT token to a URL or path element, the token SHOULD first
@@ -383,7 +686,7 @@ to define and is not constrained by this specification.
383686

384687
# Security Considerations
385688

386-
TODO Security
689+
TODO Add security considerations for DPoP Claims
387690

388691

389692
# IANA Considerations

0 commit comments

Comments
 (0)