Views
2 years ago

Contract: 027617 SPICE WP 2 Deliverable 2.5 Exposure ... - ist-spice

Contract: 027617 SPICE WP 2 Deliverable 2.5 Exposure ... - ist-spice

Contract: 027617Deliverable ReportPeriod covered: M00 – M184.2 Elements of Access Control4.2.1 Main ConceptsEnvironmentSubject«consider«identifyPolicy«permit/denyActIdentity«managePAP(PolicyAdministration Point)PIP(PolicyInformation Point)«useResource«evaluatePDP(Policy DecisionPoint)«identify«contact«rely_onPEP(PolicyEnforcement Point)«secureSecurityServices«trustFigure 7: Main concepts of access controlFigure 7 depicts the main concepts by means of UML classes, associations anddependencies. The policy-related notions are borrowed from XACML [9]. The figure readsas follows. The task is to control the Actions of certain Subjects on Resources. A Subjectmay be a user, a SPICE service component (SC), a third-party component, etc. An Actionis e.g. calling a method of a SC. A Resource may be a SC, user data, etc. in SPICE. APolicy basically declares who (Subject) may do what (Action) on what (Resource) underwhat circumstances (conditions, Environment). Policies are managed — created, deleted,modified — via a Policy Administration Point. The actual access control is performed by aPolicy Enforcement Point (PEP) by enforcing authorization decisions; a PEP typicallyresides in the messaging path and is able to block messages. A PEP typically contacts aPolicy Decision Point (PDP) for making an authorization decision; the PEP formulates adecision request, passes it on to the PDP which then evaluates the applicablepolicy/policies and renders an authorization decision. The PDP (or alternatively the PEP)may use an additional entity called Policy Information Point (PIP) for retrieving additionalinformation needed for the decision; an example PIP is the Subscription Manager which isable to return information on who is subscribed to a given service or SC. When dealingwith Subjects and Resources, a PEP relies on Identities which are secured by SecurityServices (cf. section 4.2.3). The entity implementing the Security Services is a trustedentity for a PEP. A more detailed description of the concepts can be found in deliverablesD6.2 [6], D6.3 [7] and the forthcoming D6.4 [8].4.2.2 Trust ModelCommunication between a SPICE platform at operator A and a SPICE platform atoperator B is possible only if A and B mutually trust each other. Trust is defined as thevalidity of the following two assumptions:ID: SPICE_D2.5_Ericsson Date: 28/06/2007Revision: d0.16Security: CONFIDENTIAL – Consortium onlyPage 24/34

Contract: 027617Deliverable ReportPeriod covered: M00 – M18• The communication between the parties is secure. Security of communication heremeans (1) authenticity of data origin a.k.a. identity, (2) data integrity, (3)confidentiality (optionally) and (4) anti-replay protection (optionally).Communication is secured by technical measures as described later.• The other party is friendly i.e. it is not assumed to do malicious actions.Friendliness can be ensured by means of legal measures (written contract betweenA and B, similarly to roaming agreements); this is outside of our scope. Theremight also be technical measures for ensuring friendliness, but again, these areoutside of our scope currently.Note that the above definition of trust is dedicated to our purposes in SPICE, and as suchis quite limited in scope. More details on this subject can be found in the forthcomingdeliverable D6.4 [8].4.2.3 Security ServicesSecurity services ensure the security of communication between parties (of different trustdomain). They correspond to the four aspects of secure communication listed in theprevious section, namely:(1) authentication of data origin a.k.a. identity,(2) data integrity,(3) confidentiality (optional) and(4) anti-replay protection (optional).Security services are best implemented separate from the rest of platform elements. Thissaves service and component developers (even the developers of PEPs, PDPs, Broker,etc.) from the burden of implementing security features and makes the platform easier tomaintain and configure. Borrowing the term from the 3GPP specification of IP networklayer security [10], the elements implementing the security services are called SecurityGateways (SEGs).Security Gateways (SEGs) in SPICE possess the following characteristics:• Reside on the border of platform operator networks with all inter-platform SPICEtraffic passing through them. Note that user-platform traffic flows via differentchannels (cf. AAS in the SPICE access control architecture).• They provide the necessary security services (1-4 as above). I.e., a pair of SEGs(at operator A and B, respectively) establish a point-to-point secure channelbetween operators A and B.• At each operator, there is one logical SEG per foreign operator. This allows forclean and easy configuration of SEGs, in accordance with the pair-wise legalagreements between the platform operators.• SEGs are transparent to the upper layers.For IP network layer security, TS 33.210 mandates a subset of IPsec [11]. Though thiswould be sufficient for SPICE, it is not necessary. Other technologies (e.g. HTTPS, XMLID: SPICE_D2.5_Ericsson Date: 28/06/2007Revision: d0.16Security: CONFIDENTIAL – Consortium onlyPage 25/34

SPICE WP N°: 1 Deliverable N°: 1.6 Title: Legal and ... - Bad Request
D1.7 Title: Revised business analysis and models - ist-spice
Addressing the challenges of Beyond 3G service delivery ... - ist-spice
Deliverable 2.1b, TAMES-2, IST Project 2001-34283 Version 1.0 ...