1 / 14

Extended QoS Authorization for the QoS NSLP

This draft discusses different approaches for extended QoS authorization in the QoS NSLP, including two-party, token-based, and generic three-party models. It addresses challenge/response-based schemes and extensible authentication protocols. The draft also explores technical issues, such as channel binding and interworking with NTLP security.

jcreekmore
Download Presentation

Extended QoS Authorization for the QoS NSLP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related