Network access authentication and authorization based on SAML

1. Network access authentication and authorization based on SAML Antonio F. Gómez Skarmeta Universidad de Murcia, Spain skarmeta@dif.um.es

2. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocol extensions • Conclusions

3. VPN Device VPN Device LDAP LDAP LDAP End End End User User User Server Server Server Administrator Administrator Administrator Certification Certification Certification WWW Secure WWW Secure Authority Authority Authority Request Server Request Server Registration Registration Registration Registration Authority Authority Authority Authority IPv6 Plain connection IPv6 SSL connection SCEP SCEP or SSH/SCP over IPv6 SCEP Data Base Data Base Data Base PKIv6 Architecture

4. Introduction • Security technologies to offer network acess control based on authentication of users • login/password • public key certificates (PKCs) • Environments where user’s are classified: • administrative tasks • type of service obtained • For example: University environment • administrative staff, • professors, • students, • researchers,... • Look for flexible service provision

5. Introduction • Objectives: • To define a network access control approach based on: • X.509 PKC authentication • Attributes authorization • To use SAML and XACML to express: • access control policies • authorization statements • authorization protocols • To use a network scenario based on the AAA architecture

6. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocols extensions • Conclusions

7. Network Requirements (I) • AAA Server • Responsible for receiving and processing authentication, authorization and accounting requests • Use of ASM to add functionality • Network Access Technologies • The end users query a Network Access Point (NAP) whether they can access to the network • Options: 802.1X, PANA • Both are easily integrated with EAP • EAP needs to be extended to transport authorization data.

8. Network Requirements (II) • Transport of Authorization Data: • We need a protocol able to transport authentication, authorization and accounting requests from the NAP to the AAA server • Options: RADIUS, DIAMETER • DIAMETER offers a higher degree of flexibility and can be used more efficiently • Needs to be extended to transport authorization data • Inter-domain scenarios require: • to exchange user’s attributes • to know how to interpreter those attributes • An Service Level Agreement (SLA) is required between the involved domains

9. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocols extensions • Conclusions

10. Architectural elements • End User: • Entity requesting access to the network • Requires an X.509 PKC • AAA Server • Based on DIAMETER • Requires two ASM modules: • Source Authority (SA) • Policy Decision Point (PDP) • Source Authority (SA) • Manages the assignment of roles to users • Manages the Role Assignment Policy • Role Assignment Policy • “in the source domain Source, the set of roles R1, R2.. Rn can be assigned to the users contained in the o=org,c=ES X.500 sub-tree for the period V” • Based on XACML

11. Architectural elements • Policy Decision Point (PDP) • Generates the statements related to authorization decisions • Manages the Resource Access Policy • Policy Administration Point (PAP) • Defines, signs and publishes the Resource Access Policy • Resource Access Policy • “the users pertaining to the source domain Source, and playing the role R1, will get access to the network N1 with a QoS1” • Based on XACML • Network Access Point (NAP) • forwards the client requests to the appropriate AAA server of the target domain • obtains and enforces the properties of the network connection

12. Architectural elements • Application scenario SA: Role Mng PDP: Statement Gn Policy: User-Role1 QoS=q cert

13. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocols extensions • Conclusions

14. Design alternatives • Pull model: • minimum overload • more suitable for limited terminals • authorization tasks are performed internally • Push model: • the user can present a set of attributes • involves support for selecting and transporting attributes from the end user terminal • a more intrusive approach • In both alternatives: • user authentication based on 802.1X • exchange of EAP packets between the user and AAA server • AAA enforces EAP-TLS to authenticate the user

15. Pull model • Pullmodel: • Authorization is made in a transparent way • PDP recovers all the information needed to make the decision • The user can not select the set of properties to be satisfied by the connection • Two different scenarios: • Intra-domain scenario • Inter-domain scenario

16. Intra-domain Pull model

17. Inter-domain Pull model

18. Push model • Pushmodel • End users are able to present their authorization credentials • SAML attribute statements contain the roles played • End users can obtain their attributes: • from their home domain • when they are connected to a restricted foreign network • End user has to select which attribute(s) is going to present as evidence, and, optionally, which kind of network service wants to obtain • It provides to the end user a complete visibility and control of the authorization process • he can select the type of connection, security properties, QoS, etc. • Client software must be modified in order to deal with SAML statements

19. Inter-domain Push model

20. Recovering user attributes Home domain recovery Foreing domain recovery

21. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocols extensions • Conclusions

22. Protocols extensions • EAP-SAML • Used in the push model • User has to present his credentials • Based on PEAP(Protected EAP) • After the EAP-TLS exchange • PEAP packets to transport SAML authorization data • DIAMETER-SAML • Used in inter-domain scenarios (pull and push models) • Exchange of SAML authorization data between AAA servers • User credential recovery process (push model) • Exchange between DIAMETER client application (WS) and the AAA server

23. Broadcast security: Key group management DVB - T Daidalos Scenario • Interdomain Key Management • Key life-cycle Protocols: CMC AAAH AAAF IPsec IPsec Open Source Diameter IPsec PKI Key/Cert Provision PAA IPsec PANA + EAP-TLS PAC AAA-AA Integration Authentication: • PANA + EAP Registraton (Authorization): • SAML + EAP

24. Integration • Infrastructure A4C+AA provide: • Authentication (based on cert) • Credentials for services access (based on Token-ID) • ´PANA as a bootstrapping protocol: • provide the transport for independent access network and for EAP contents exchange • Network and associated services • KDC is the entity to provide the TTP needed, initially PKI but future integrate other approaches

25. Current Work(I) • Authentication based on: • Public/private keys i.e certificates provided by PKI linked to a VID • EAP, in particular EAP-TLS transported by PANA between MT-AR and Diameter EAP between AR and A4C • Keys generated by EAP-TLS are used to establish PANA SA and IPSec SA between MT and AR.

26. Current Work(II) • The user selects a specific VID for authenticating at the authentication authority. • Using A4C mechanisms, the VID and its credentials are routed to the authentication unit at the “home provider”. • Provided credentials are verified and the user authenticates against the access management system. • The authentication authority requests the generation of an authentication assertion (based on the successful authentication) from the Asserting Authority. • The Asserting Authority maps the VID to the RegID, creates an authentication assertion and ID-Token, both directly related to the RegID • The ID-Token including the SAML artifact, is sent to the Mobile Terminal (MT), where it is stored for further service requests and network access authorizations ID-Token Separate authentication from network service authorization

28. Fast-reauthentication • AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments", length) • AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for multiple attachments", AAA-Key, B-Called-Station-Id, Calling-Station-Id,length) • This AAA-key is used to derive new keys for generating PANA SA and IPSec SA.

29. Testbed • Pull and Push models working based on 802.1X • Integration with PANA in progress • EAP-SAML and DIAMETER-SAML extensions working • Multidomain homogeneous and heterogeneous scenarios working • Integrated with PERMIS scenarios • High level application support • Grid as application service

30. Content • Introduction • Scenario Requirements • Architectural elements • Design alternatives • Protocols extensions • Conclusions

31. Conclusions (I) • Authorization solution for network access scenarios • Integration of different technologies in a effective way • It provides a wide range of real possibilities to design a network access control system • It makes use of widely-accepted standars • Scenario based on 802.1X, but can be easily adapted to PANA • EAP and DIAMETER protocols need to be extended to transport SAML sentences

32. Conclusions (II) • Authorization mechanism based on SAML and XACML • It presents to different RBAC solutions • pull model, transparent for the end users • push model, intrusive for the end users, but more flexible

33. Thanks for your attention Questions to: gabilm@dif.um.es ocanovas@um.es rafa@dif.um.es skarmeta@dif.um.es