Session ID Georg Carle, John Vollbrecht, Sebastian Zander, Tanja Zseby San Diego, December 2000

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 2 Overview Binding Objectives Binding Concepts Related Work Requirements Session ID Generation Examples Summary

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 3 Binding Objectives Authentication, Authorization and Accounting with the Service provisioning process (Service Session) Accounting records (maybe generated by different hosts) which provide the accounting data for the services a user has used Different service sessions that logically belong together Binding needed for Auditing and Accounting

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 4 Binding Objectives Time Service Usage Session Subsession 1 AuthAuthoriz Subsession 2 Accounting

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 5 Binding Concepts Hierarchical Binding: Subsession IDs are derived from supersession (e.g. key ring approach) Peer-to-peer Binding: Two equal sessions without specifying hierarchy Late Binding: Binding is not done during session lifetime but is created later if needed based on attributes (e.g. IP address, start time)

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 6 Related Work RADIUS DIAMETER WWW based Services RTSP SIP SDP/SAP

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 7 Requirements Binding –Flexibility –Scalability Session ID –Globally unique –Privacy Security is important

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 8 Session ID Generation Server generates ID during initial message exchange (e.g. authentication) –user and/or server specific information –time or increasing number –cryptographic hash Simple scheme to create global unique ID: AAA ID + Service ID + Session ID AAA ID: Global unique ID of the AAA server Service ID: Identify a service at a AAA server Session ID: Unique ID in the scope of the service

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 9 Example: VoD over Diffserv 1 User CP: Content Provider TP: Transport Provider CP TP 1TP 2 Y (Diffserv Access) X (Content) Z (Diffserv) ID: X ID: Z ID: X ID: Y X Y Z Y Z

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 10 Example: VoD over Diffserv 2 User CP: Content Provider TP: Transport Provider CP TP 1TP 2 Z (Diffserv Access) Y (Content) X (Diffserv) ID: Y ID: X ID: Y ID: X XY Z Z Z

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 11 Z Example: VoD over Diffserv 3 User CP: Content Provider TP: Transport Provider CP TP 1TP 2 Y (Diffserv Access) X (Content) V (Diffserv) ID: X ID: V ID: X ID: V W X YZ W (Diffserv) VW TP 3 ID: W Y Y Z, Z

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 12 Example: VoD over Diffserv 3 Auditing –auditing information is transferred to trusted server during session lifetime –binding is done when needed (i.e. audit request) user audit_server: query X audit_server CP: X... audit_server user: audit info X, Y, Z, V, W

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 13 Summary Currently only AAAARCH internal draft Terminology Problem Statement Related Work Requirements Examples Number of open issues

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 14 The End

San Diego IETF, December 2000: AAAARCH Meeting - Session ID 15 Open Issues How does this work with the different authorization models (RFC2904) Do we need to encode session hierarchy in the session id? More precise definitions (i.e. subsession) Look at SIP, RTSP, SDP/SAP More examples rework existing concepts