1. Extended QoS Authorization for the QoS NSLP Hannes Tschofenig, Joachim Kross

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 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 QoS Request Entity requesting resource Entity authorizing resource request granted/rejected End Node Node within the attached network

4. Three-Party Approach Token based Mechanism 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] QoS Request + Token Entity requesting resource Entity performing QoS reservations granted/rejected Entity authorizing resource request (TTP) Authz Token Request Authz Token

5. Three-Party Approach Entity Authentication 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 Entity authorizing resource request QoS Authz Request QoS Authz Response

6. Generic Three Party Approach Comparison 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 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) Entity requesting resource Entity performing QoS reservations Unauthorized (challenge) Entity authorizing resource request QoS Request+Response Success/Failure AAA-QoS (Identity) AAA-QoS (challenge) AAA-QoS (response) AAA-QoS (success/failure)

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

9. Technical Issues C/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 ANetwork C Node A Node B Network B 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

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 See also related activities in AAA working group. AAA Client NSIS Initiatior Network Entity NSIS AAA Server COPS / Diameter Authentication and Authorization Credentials Back - end AAA Server