Upload
sian
View
45
Download
4
Tags:
Embed Size (px)
DESCRIPTION
Network access authentication and authorization based on SAML. Antonio F. Gómez Skarmeta Universidad de Murcia, Spain [email protected]. Content. Introduction Scenario Requirements Architectural elements Design alternatives Protocol extensions Conclusions. VPN Device. VPN Device. - PowerPoint PPT Presentation
Citation preview
Network access authentication and Network access authentication and authorization based on SAML authorization based on SAML
Antonio F. Gómez Skarmeta
Universidad de Murcia, Spain
2
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocol extensionsConclusions
3
PKIv6 ArchitecturePKIv6 Architecture
WWW Secure Request Server
Data Base
LDAP Server End User
Certification Authority
Registration Authority
Administrator
IPv6 SSL connection
IPv6 Plain connection
SCEP
VPN Device
WWW Secure Request Server
Data BaseData Base
LDAP ServerLDAP Server End UserEnd User
Certification Authority
Certification Authority
Registration Authority
Registration Authority
Registration Authority
AdministratorAdministrator
SCEPSCEP or SSH/SCP over IPv6
VPN Device
4
IntroductionIntroduction
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
IntroductionIntroduction
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
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocols extensionsConclusions
7
Network Requirements (I)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)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
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocols extensionsConclusions
10
Architectural elementsArchitectural 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 elementsArchitectural 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 elementsArchitectural elements
Application scenario
SA: Role Mng
PDP: Statement Gn
Policy: User-Role1QoS=q
cert
13
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocols extensionsConclusions
14
Design alternativesDesign 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 modelPull model
Pull model:– 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 modelIntra-domain Pull model
17
Inter-domain Pull modelInter-domain Pull model
18
Push modelPush model
Push model– 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 modelInter-domain Push model
20
Recovering user attributesRecovering user attributes
Home domain recovery Foreing domain recovery
21
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocols extensionsConclusions
22
ProtocolsProtocols extensions 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
PAA
DVB - T
PAC
AAAF AAAH
PKI
Open Source Diameter
IPsec
IPsec
IPsec
IPsec
Authentication:•PANA + EAP
PANA + EAP-TLS
Broadcast security: Key group management
Key/Cert Provision
Registraton (Authorization):•SAML + EAP
Daidalos Scenario Daidalos Scenario • Interdomain
Key Management
• Key life-cycle Protocols: CMC
AAA-AA Integration
24
IntegrationIntegration
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)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)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
Random Number Serial Number Artifact
Signature (by using Sender’s private key)
VID=string@realm
Encrypted by using Receiver’s public key
ID-Token
Separate authentication from network service authorization
27
Access RouterMT
MT(PaC) MT(QoS Client) PAA QoS Entity QoS Broker A4C/SAML
PSR(EAP-Request/Identity)
Diameter-EAP-Ans(EAP-TLS-Req/Start)
Diameter-EAP-Req(EAP-Response/Identity(VID),Calling-Station-Id AVP)
PAR(EAP-TLS-Req/Start)
PAN(EAP-TLS-Resp/[TLS-Client-Hello])
Diameter-EAP-Req(EAP-TLS-Resp/[TLS-Client-Hello])
Diameter-EAP-Ans(EAP-TLS-Req/[TLS-Server-Hello/Certificate])
PAR(EAP-TLS-Req/[TLS-Server-Hello/Cert.])
PAN(EAP-TLS-Resp/[TLS-Certificate])
Diameter-EAP-Req(EAP-TLS-Resp/[TLS-Certificate])
Diameter-EAP-Ans(EAP-TLS-Req(TLS-finished))
PAN(EAP-TLS-Resp)
Diameter-EAP-Req(EAP-TLS-Resp)
PBA(MAC-Addr AVP)
{Authentication + Generate SAML Assertion & ID-Token}
{Authenticated}
Authentication Phase + Artifact Delivery +Registration in the same PANA session
(example with EAP-TLS)
PDI
Identity Verification
PAR(EAP-TLS-Req(TLS-finished))
{Registered}
Diameter-A3S-Req(SAML-Request(ID_token))
Diameter-A3S-Ans(SAML-Response(NVUP Assertion))
{NVUP Assertion is present}COPS Decision
PUA()
IPSec establishment
Access Commit
Network Qos(VID,ID-token)
PUR(SAML-ID_token-AVP)
PSA(EAP-Response/Identity(VID))
Diameter-EAP-Ans(EAP-Success,EAP-MSK-AVP,SAML-ID_token-AVP,Service-Data-Authz AVP)
PBR(EAP-Success/SAML-ID_token-AVP,Service-Data-Authz AVP)
COPS Request(VID,ID-token)
28
Fast-reauthenticationFast-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.
Access RouterMT
MT(PaC) MT(QoS Client) PAA QoS Entity QoS Broker Home A4C/SAML
PSR(EAP-Request/Identity)
{Registered}
Registration Phase
PDI
IPSec establishment
Identity Verification & AAA-key generation
COPS Request(VID,ID-token)
Diameter-A3S-Req(SAML-Request(ID-token))
Diameter-A3S-Ans(SAML-Response(NVUP assertion))
{NVUP Assertion is present}
COPS Decision
PBR(Service-Data-Authz AVP)
PBA(MAC-Addr AVP)
Network Qos(VID,ID-token)
Diameter-EAP-Req(EAP-Resp/Identity(VID),Called-Station-Id AVP,Calling-Station-Id AVP,SAML-ID_token-AVP)
Diameter-EAP-Ans(EAP-Success,EAP-MSK AVP,Service-Data-Authz AVP)
PSA(EAP-Resp/Identity(VID),SAML-ID_token-AVP)
Access Commit
29
TestbedTestbed
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
Application Version Use
OpenDiameter 1.0.7-d To implement AAA
infrastructure
Jakarta Tomcat 4.1.30 PDP and SA
OpenSAML 1.0 C++
1.0.1 - Java
SAML functionality
SunXACML 1.2 XACML policies
30
ContentContent
IntroductionScenario RequirementsArchitectural elementsDesign alternativesProtocols extensionsConclusions
31
ConclusionsConclusions (I) (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
ConclusionsConclusions (II) (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
Thanks for your attentionThanks for your attention
Questions to:[email protected]@[email protected]@dif.um.es