Extended QoS Authorization for the QoS NSLP

1. <draft-tschofenig-nsis-qos-ext-authz-00.txt> Hannes Tschofenig, Joachim Kross Extended QoS Authorization for the QoS NSLP

2. Overview • Current status of the QoS NSLP: • Two party approach (reuses properties of GIMPS) • Token-based three party (based on token concept defined for SIP/RSVP) • Generic three party approach discussed but no solution provided • Draft addresses two approaches for the generic three party model • Challenge/Response based Scheme • Extensible Authentication Protocol Approach

3. Two-Party Approach QoS Request Entity requesting resource Entity authorizing resource request granted/rejected • Properties: • Strong trust relationship between "Entity authorizing resource request" and "Entity performing QoS reservation" • Typically: Data-origin authentication sufficient • Financial establishment pre-established based on previous protocol execution • Examples: • Network access authentication reused for QoS authorization End Node Node within the attached network

4. Three-Party ApproachToken based Mechanism Entity authorizing resource request (TTP) • Financial establishment created between "Entity authorizing resource request" and "Entity performing QoS reservation" • Example: • Session Authorization Policy Element [RFC3520] • Framework for Session Set-up with Media Authorization [RFC3521] Authz Token Request Authz Token QoS Request + Token Entity requesting resource Entity performing QoS reservations granted/rejected

5. Entity authorizing resource request Three-Party ApproachEntity Authentication QoS Authz Request QoS Authz Response • Financial establishment created between "Entity authorizing resource request" and "Entity performing QoS reservation" • Properties: • AAA-type authorization - splitting functional components • Dynamic re-authorization based on new incoming requests. • Typically: entity authentication between "Entity requesting resource" and "Entity authorizing resource requests" QoS Request Entity requesting resource Entity performing QoS reservations granted/rejected

6. Generic Three Party ApproachComparison with Token-based Approach • Features: • End host must actively participate in the protocol exchange • True authentication between the end host (user) and the AAA server. • Session key establishment is provided • Provides better security properties • Difference between EAP and C/R based approach is mainly flexibility: • With C/R based scheme a specific family of authentication and key exchange protocol is chosen • If this does not fit into an architecture then there is a problem. • With EAP this type of flexibility is provided since EAP acts as a container for many EAP methods • EAP is heavily used in other areas (e.g., network access)

7. Challenge/Response-based Authentication Entity requesting resource Entity performing QoS reservations Entity authorizing resource request • Challenge/Response based authentication protocol extensions to the QoS NSLP • Could be reused by some architectures (3GPP, 3GPP2) with their C/R based authentication and key exchange protocol variant QoS Request (Identity) AAA-QoS (Identity) Unauthorized (challenge) AAA-QoS (challenge) QoS Request+Response AAA-QoS (response) Success/Failure AAA-QoS (success/failure)

8. EAP-based Approach Entity requesting resource Entity performing QoS reservations Entity authorizing resource request • Advantage: More flexible due to the concept of EAP methods • Disadvantage: Overhead by EAP QoS Request (EAP-Request/Identity) AAA-QoS (EAP-Request/Identity) Unauthorized (EAP-Request/AKA-Challenge) AAA-QoS (EAP-Request/AKA-Challenge) QoS Request (EAP-Response/AKA-Response) AAA-QoS (EAP-Response/AKA-Response) NSIS (EAP-Success/Failure) AAA-QoS (EAP-Success/Failure) Legend: AKA-Challenge: (AT_RAND, AT_AUTN, AT_MAC) AKA-Response: (AT_RES, AT_MAC)

9. Technical IssuesC/R and EAP • Channel binding might be necessary to prevent Man-in-the-Middle attacks. • Binding NSLP and NTLP security mechanisms together. • Session keys need to be established and used in subsequent messages in order to bind signaling messages to the authentication/authorization step • Interworking with NTLP security needs to be studied: • Unilateral authentication at the NTLP layer • Client authentication at the upper layer • 'Lying NAS' problem needs to be addressed. • A lot of security specific issues need to be addressed

10. Next Steps • For the QoS NSLP to make progress it is necessary to decide which approach to use: • Challenge/Response based approach • EAP-based approach

11. Questions?

12. Backup

13. Trust Model: New Jersey Turnpike Model Network A Network B Network C • Peering relationship is used to provide charging between neighboring networks - similar to edge pricing proposed by Schenker et. al. • David Clark: "We know how to route packets, what we don't know how to do is route dollars." Data Sender Data Receiver Node B Node A

14. Authentication, Authorization and Accounting Infrastructure • Authorization might not always happen at an NSIS element itself (see roaming scenarios) • Information which is exchanged between the end host (e.g., NI) needs to be forwarded to a backend server (e.g., PDP or AAA server) • NSIS and AAA protocols need to aligned Authentication and Authorization Credentials Back - end NSIS COPS / Diameter NSIS Initiatior AAA Network Entity Server AAA Client AAA Server • See also related activities in AAA working group.