Work Package 4
Authentication, Authorization andAccounting
Leon Gommans, Mihai Cristea, Yuri Demchenko
University of Amsterdam
Kick-off meeting Poznan October 17th

Overview! Introduction! What: Description of WP4 from technical annex! How:• AAA concepts• AAA within GMPLS networks• AAA at network exchange points• Two presentations on some implementation details

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_1

Introduction! Authentication: Who are you ?
! Authorization: What are you allowed to do ?
! Accounting: How much have you used ?
! Focus of projects is towards authorization assuming someform of authentication will be used.
! Demand and Supply side.
! Multiple Independent Suppliers,! Demand side represented by multiple organizations! Only if accounting is implemented, suppliers will want tocollaborate.
! Accounting is second objective.
! AAA systems handle AAA requests and (policy based)
decisions using some format. Focus is both on handling andmessage formats.
PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_2

WP 4 Objectives PM 1 - 18!

WP4 (Service Plane - AAA) will focus on implementing and integrating
Authentication, Authorization and Accounting solutions for the PHOSPHORUS
test-bed. The objectives of WP4 in the first 18 month are:
1. To study the applicability of current and emerging AAA related technologies in order to select asuitable set with enough flexibility to create and test the interoperability of optical network
domains. Collaborations with GÉANT2 (JRA5), DRAGON and EGEE will be established which
and will be used as a base.
2. Collaborate with WP1, 2 and 3 to establish their specific needs towards AAA and describe
their needs in a uniform way that allowing a more generalized implementation
3. To create prototypes, running in a test bed, which demonstrates authorization sequences
applied in multiple functional layers of the network. The AAI work within GÉANT2 and VOMS
work within EGEE will be used as starting point and expanded.

!

Consequently the work is organised into•

Task 4.1

AAA architecture selection•

Task 4.2

AAA scenario development•

Task 4.3

Integration and testing

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_3

Task 4.1 AAA Architecture Selection
Work of relevant network standards bodies (IETF, GGF, TGC, OIF, ITU-T, IEEE),
European or national Grid projects (EGEE, Globus, Unicore, etc.) and optical
networking projects (GアNT2, GLIF, VIOLA) will be considered and theirarchitectures will be briefly described and classified. This work will be used toposition AAA technologies such that selections can be made to create
interoperable scenarios between optical network domains in the test-bed.
Activity 4.1.1 - Consider standard bodies based AAA architectures
Activity 4.1.2 - Consider Grid projects based AAA architectures
Activity 4.1.3 - Consider optical networking projects AAA and AAI architectures
Activity 4.1.4 - Selection of AAA architectures for test-bed.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_4

Task 4.2 AAA scenarios
RFC2904 and GFD.38 provide sequence models that describe an authorization process. Thistask will work with WPs 1,2 and 3 to describe AAA scenarios used within their WP by using
the standards documents as a guideline. This WP will subsequently work on creating a
number of different test scenarios involving available solutions and experiences from theimplementations in the test-bed. The work is aimed at testing a set of AAA mechanisms
capable of unifying the AAA process across multiple domains using different solutions.
AAA/AAI mechanisms used within GアNT2 (JRA5), gLite (EGEE) and Globus GT4 will beconsidered. Experience with these scenarios will help to identify advantages anddisadvantages of particular approaches. It will also identify missing functionality.
Performance, manageability, scalability are important considerations. Reporting will be donein D4.2.
!

Activity 4.2.1 - Interact with WP1 and create AAA scenario.
This activity will study WP1 to identify AAA sequences interacting within- or with an NRPS.

!

Activity 4.2.2 - Interact with WP2 and create AAA scenario
identify AAA sequences interacting within the GMPLS control plane or via the G-OUNI.

!

Activity 4.2.3 - Interact with WP3 and create AAA scenario.
identify AAA sequences within Grid Application scenarios or via the G-OUNI.

!

Activity 4.2.4 - Create ForCES based token based scenario.
the deployment of the RFC2904 token sequence in networking deployed within the IETF ForCES
framework.

!

Activity 4.2.5 - Create AAA scenarios for test bed.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_5

Task 4.3 Integration and testingThis task will integrate the selected AAA technologies into a test bed and perform
experiments in collaboration with WP6. Test scenarios will be determined incollaboration with WP 1, 2 and 3 by task 4.2. This task will execute the definedtests and report results. This work will specify the required facilities incollaboration with WP6. This work will focus on creating inter-domain AAA
scenarios as preparation to a (pre-)production network such as GアNT2, to beconsidered in the second phase of this project.
!

Activity 4.3.1 - Integrate selected AAA mechanisms in test bed
This activity will technically implement the AAA mechanisms selected in task 4.1!

Activity 4.3.2 - Create technical implementation plans for test scenario's
This activity will technically implement the test scenarios defined in task 4.2.

!

Activity 4.3.3 - Perform test scenarios
This activity will perform the test scenarios and report the results in D4.2.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_6

WP 4 Milestones PM 1-18
! M4.1 – AAA architectures to be described are identified and selected(M6)• This activity will consider protocols, languages and mechanisms that are
currently being used to implement authentication, authorization and accountfunctions in a Grid context. From this set, a selection will be motivated to
implement scenario's that will be coordinated with WP1/2 and 3. AAA
scenario's will involve both the Service Plane, which interfaces with thecontrol plane as well as consider scenario's that involve s the data-forwarding
plane.

! M4.2 – Selected test-bed scenarios are implemented (M12).
• The selected functions will be implemented in the tested, which can perform anumber of identified scenario's.

! M4.3 – Selected test-bed scenarios have been tested (M18).
• The selected scenario's have been tested such that the can be compared andevaluated in terms of performance, flexibility or scalability.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_7

WP 4 Milestones PM 19 - 30
! M4.4 - Study to integrate findings into larger deployment scenario(e.g. GÉANT2/GLIF) completed (M24)• The scenario's from M4.3 will now be considered for implementation andintegration into a larger test-bed using external networks such as GÉANT2
and the GLIF.

! M4.5 - Selected large scale deployment scenario(s) have been tested(M30).
• The large scale scenario's have been tested and documented.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_8

WP 4 Deliverables PM 1 - 18
! D 4.1 AAA Architectures and scenario's for multi-domain optical
networking.
Based on studies (both theoretical and from experienced gained in the
test-bed) performed in Task 4.1 and collected input from WP1, 2 and 3(Task 4.2) this deliverable will describe and motivate scenario's anddesigns that are expected to demonstrate interoperable use of AAA andAAI components for implementing multi-domain optical networking.
! D 4.2 AAA scenario's and test-bed experiences.
Based on the motivated design and scenario's described in D4.1, thisdeliverable will describe the experiences gained from deploying AAA andAAI components in the test-bed to create an end-to-end lightpath acrossmultiple domains.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_9

WP 4 Partners + Personel

Task
Task 4.1

Deliverables & Partners Contributions
D4.1
UvA, FHG, University of Bonn.

Task 4.2

D4.2
UvA, HEL, CTI, NORTEL

Task 4.3

D4.2
UvA, HEL, CTI, NORTELPHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_10

AAA concepts: RFC 2904 Authorization sequences

AUTHORITY

1
USER

2
PUSH
Sequence

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_11

AAA concepts: RFC 2904 Authorization sequences

AUTHORITY

2

USER

1
PULL
Sequence

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_12

AAA concepts: RFC 2904 Authorization sequences

AUTHORITY

1
USER

AGENT
Sequence

2

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_13

AAA concepts: Combination example

AUTHORITY

1
2

USER

3
TOKEN
Sequence

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_14

AAA concepts: Token Sequence in more detail

AUTHORITY

Authorization
RequestOR
USER

Service +RequestRESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_15

Tokens and GMPLS

AUTHORITY

Authorization
RequestOR

GMPLS
Client

RSVP-TE
Request

+
GMPLS
LSR

Contained within
RFC 2750 RSVPExtension
PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_16

Tokens inside IP packets

AUTHORITY

Authorization
RequestOR

IP
ClientIP Packet

Authorized
IP packets+

Token BasedRouter

E.G. IPV4
Options Field

PHOSPHORUS kick-off, 17-18 Oct. 2006

Other
IP packets

Slide_17

Which, What, Where and How! Which sequences are applicable in WP 1,2 and 3 and describe them.
! Which (standard) message formats should be used where.
! What mechanisms are applicable where:• Inside the Authority, Resource and User
• What ( standards based) technology can be used to build required functions• Include multiple service domains that may work with different technologies! How to further organize interactions with WP1, 2 and 3• Common organized inter-WP meetings ?
• WP 4 specific meetings ?

! When / where / how frequent ?
! Intentions to setup collaborations with organizations outside project thatare not EU funded such as Internet2, DRAGON - how to proceed ?

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_18

Next presentation #1: Mihai Cristea! Router based Processing of IP Packets with tokens! Router may use FORCES architecture

TransitNetwork
Normal IP packets

Token
RouterToken
RouterNRN

Token IP packets

NRN

GMPLS
Network

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_19

Next presentation #2: Yuri Demchenko

AUTHORITY

1
USER

2
3

TOKEN
Sequence

Standards
Interoperability
Multi-domain
Attributes
Trust
Integrity
Confidentiality

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_20

Efficiency and Performance Issues inToken Based Switch Systems

Mihai Cristea
University of Amsterdam
PHOSPHORUS Kick-off meeting - Poznan 17-18 October 2006

Token based path selection at interconnection
points - demo at SC-05
TransitNetwork

Unauthorized
Traffic

HybridISP B

Hybrid
ISP A

U

ICP
A

Stakeholder
Links

ICP
B

V

Lambda Grid

Issue right to use

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_22

Why tokens?

! Tokens are a simple way to authorise
resource usage;! Can bind to differrent semantics;! Decouple time of authorisation from time ofuse.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_23

TBS Architecture

Link Access Request

U1

1
AAA Server

Link Admission
Request to other PPs
Link Admission
Policy Repository

2

Token Builder
ISP A

3

Link Stakeholder1

Token
Based
SwitchU2Peering Point A

PHOSPHORUS kick-off, 17-18 Oct. 2006

Link Stakeholder2

BGP
routerTo Transit Network

Slide_24

Token creation

ETH_packet: ETH_hdr

Data

IP_hdr

ETH_crc

Mask:
Hdr_len tot_len Hdr_chks

Data toencrypt
64 bytes

Token key
(20bytes)

HMAC-SHA1
ETH_hdr

IP_hdrToken(20 bytes)
IP_options

Data

ETH_crc

24 bytes

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_25

HW platform: IXDP2850
SRAM
SRAM
SRAM
16 µEngines

DRAM
DRAM
DRAM

PCI bus

AES,
AES,
3DES,
3DES,
SHA-1
SHA-1

XScaleIXP2850: Ingress NPU
10x1Gbps

Fabric Interface
Chip

IXP2850: Egress NPU
16 µEngines

AES,
AES,
3DES,
3DES,
SHA-1
SHA-1

SRAM
DRAM
SRAM
DRAM
SRAM
DRAM

Ethernet
100Mbps

XScale

PCI bus

PHOSPHORUS kick-off, 17-18 Oct. 2006

Ethernet
100Mbps

Slide_26

TokenSwitch application

Gigabit ports
Ingress

Rx
from
Gig

PBuf

EgressY’=PKT.IP_Options;
Y”=HMAC of first 64 masked bytes
if (Y’!=Y”) thenTX(port8);else
TX(port Np);

Yp=HMAC of first 64B masked
Yp=>PKT.IP_Options;
Compute IP_checksum;
TX();

MEM:SRAM[]

TBuf

CSIX

PBuf

MEM:SRAM[]

Tx
to
Gig

TBuf

sip, dip: Ku,Np

sip, dip: Ku

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_27

SuperComputing 2005 DemoInternet

Linux

BootServer
Gateway

10/100Mbps switch

6
Gigabit ports

Ingress

EgressIntel IXDP2850

PHOSPHORUS kick-off, 17-18 Oct. 2006

7Rembrandt6

Rembrandt78Rembrandt8

Slide_28

Performance

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_29

Work inside Phosphorus! Building a Token Based Router – an IP
service using an IETF ForCES based
forwarding device:• ForCES describes a framework (RFC 3746) for
modular data forwarding devices.
• Data forwarding functions implement routing,bridging, signaling, access control functions, etc.
• Token recognition can be another functional block

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_30

Conclusion! Token Based Switching application on
network processors:• Select an optical path in hybrid networks;• Admission control based on tokens;• Multi-Gigabit speeds;• Dynamically set up multiple shortcuts across amulti-domain end-to-end connection.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_31

Questions ?

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_32

Next presentation #2: Yuri Demchenko! GAAA-AuthZ components to support Complex Resource Provisioning(CRP)! Assertions format between Authority and Resource Policy Enforcement
Point
AUTHORITY

1
USER

2
3

TOKEN
Sequence

Stds&Interop
Multi-domain
Attributes
Trust
Integrity
Confidentiality

RESOURCE

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_33

GAAA-AuthZ components
to support
Complex Resource Provisioning (CRP)
Yuri Demchenko <demch@science.uva.nl>
System and Network Engineering Group
University of Amsterdam
POSPHORUS kick-off meeting, 17-18 October 2006, Poznan

Outline! Background information - Affiliated and previous projects• Moving to multi-domain dynamic AAA service infrastructure! GAAA-AuthZ components to support dynamic security context mngnt• Extended AuthZ ticket format• AuthZ security context management in multidomain AuthZ! Using TCG Trusted Computing and Trusted Network Connect platforms(TNC) for extending trusted application domain! Using XACML policy format for multidomain access control! Summary and Issues to discuss

GAAA – Generic Authentication, Authorization, Accounting
GAAA-AuthZ – GAAA AuthZ Framework

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_35

Background information – Affiliated and previous projects! EGEE-I and EGEE-II• EGEE gLite Java Authorisation Framework (gJAF)– gJAF extension to support SAML attributes, AuthZ session and full XACML policy
functionality– Integration with the GT4-AuthZ framework• LCG/EGEE Operational Security and EGEE Grid Security Infrastructure! OGSA-AuthZ WG contribution• Dynamic AuthZ service infrastructure and components! GigaPort NG Research on Network– Gap analysis of Authorisation services functionality for Optical LightPath
Provisioning (OLPP)! Collaboratory.nl project - industry funded project• Multidomain resource administration for Collaborative applications

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_36

AuthZ ticket/assertion for extended security context
management – Data model (1) - Top elements
Required functionality to support
multidomain provisioning scenarios! Allows multiple Attributes format(semantics, namespaces)! Establish and maintain Trust
relations between domains•!

!

Including Delegation

Ensure Integrity of the AuthZ
decision•

Keeps AuthN/AuthZ context•

Allow Obligated Decisions (e.g.
XACML)

Confidentiality•

Creates a basis for user-controlled
Secure session

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_37

AuthZ ticket Data model (2) - Mandatory elements

!
!
!
!

TicketID attribute
Decision element andResource attribute
Conditions Element andvalidity attributes
Extensible element
ConditionAuthzSession•

PHOSPHORUS kick-off, 17-18 Oct. 2006

Any AuthZ session related
data

Slide_38

AuthZ ticket main elements<Decision> element - holds the PDP AuthZ decision bound to the requested resource orservice expressed as the ResourceID attribute.
<Conditions> element - specifies the validity constrains for the ticket, including validity timeand AuthZ session identification and additionally context<ConditionAuthzSession> (extendable) - holds AuthZ session context<Subject> complex element - contains all information related to the authenticated Subject
who obtained permission to do the actions<Role> - holds subject’s capbilities<SubjectConfirmationData> - typically holds AuthN context<SubjectContext> (extendable) - provides additional security or session related information, e.g.
Subject’s VO, project, or federation.

<Resources>/<Resource> - contains resources list access to which is granted by the ticket<Actions>/<Action> complex element - contains actions which are permitted for the
Subject or its delegates<Delegation> element – defines who the permission and/or capability are delegated to:another Subjects or community
attributes define restriction on type and depth of delegation<Obligations>/<Obligation> element - holds obligations that PEP/Resource should
perform in conjunction with the current PDP decision.

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_39

Security context management in multidomain AuthZ:
Context dependent information and existing mechanisms! Context dependent information/attributes:•

Policy•Trust domains and authorities•

Attributes namespaces•

Service/Resource environment/domain•

Credential semantics and formats! Mechanisms to transfer/manage context related information•

Service and requestor/user ID/DN format that should allow for both using namespaces
and context aware names semantics•

Attribute format (either X.509/X.521 or URN/SAML2.0 presentation)•

Context aware XACML policy definition using the Environment element of the policy
Target element•

Security tickets and tokens used for AuthZ session management and for provisioned
resource/service identification•

Security federations for users and resources, e.g. VO membership credentials

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_40

Extending trusted application domain with TCG and TNC! TCG Trusted Computing platform (TCG) and Trusted Network
Connect platform (TNC) can create a basis for trusted user/authority
and resource/provider platforms introduction• TPM ensured remote platform integrity will allow to initiate trusted
provisioning/AuthZ session for AAA services• Includes three stages– (1) Remote platform inspection/verification (TCG and TNC)
– (2) Starting User session and Virtual WorkSpace Service (VWSS)– Provides secure executive environment for the user applications– (3) Starting Application session (GAAA-AuthZ)– Ensure Integrity and Confidentiality for the user application data

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_41

XACML Special profiles for RBAC and complex Resources! XACML RBAC profile• defines policies that require multiple Subjects and roles combination toaccess a resource and perform an action• implements hierarchical RBAC model when some actions require superior
subject/role approval to perform a specific action• can significantly simplify rights delegation inside the group of collaborating
entities/subjects! XACML Hierarchical Resource profile• defines policy format for hierarchically organised resources, e.g. file system orXML-based repositories! XACML complex Resource profile•

allows for complex request to multiple resources having the same request
context, however decision is provided per resource! XACML3 Policy Administration and Delegation profile

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_42

XACML Policy structure!

XACML Policy format

RBAC/XACMLPolicyTarget{S, R, A, (E)}XACML
PolicyRule Combination
Algorithm

Policy Target{S, R, A, (E)}
PolicySet
Rule ID#1
Policy{Rules}Rule Target{S, R, A}…

Condition
AttrDesignat

Policy{Rules}Match List

Rule ID#n

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_43

Summary and Issues to discuss! GAAA-AuthZ/GAAA-P model and basic GAAA_tk components areavailable to support Complex Resource Provisioning and dynamic AuthZ
services invocation• Need some work to integrate with the GMPLS control plane• Provisioning scenario and provisioning/AuthZ session defintion• Extending AuthZ ticket format for basic GMPLS scenarios! Policy format for multidomain GMPLS provisioning use cases•

XACML policy profile – is XACML usable here?

! TCG Trusted Computing platform (TCG) and Trusted Network
Connect platform (TNC)• Can we benefit from these technologies?

PHOSPHORUS kick-off, 17-18 Oct. 2006

Slide_44