POSSET – Policy-Driven Secure Session Transfer

POSSET – Policy-driven Secure Session Transfer

Philip Robinson1, Christian Schaefer2, Thomas Walter2

1 y

2DoCoMo Euro-Labs, Landsberger Str. 312, 80687 Munich, Germany {schaefer, walter}@docomolab-euro.com

nablers ession

e secu-rted to a ses-en ap-alidate chan-previ- a tar-igned

ore (i.e. decision whether transfer is possible or not) and after session transfer (i.e. respective se-curity context.), while tokens are utilized to identify suitable mobile devices that claim trustworthiness, which may be target of a session transfer.

on a contin- e most

trans-N and com-ice of

st per-unica-e. one

service on several devices and across several domains [9]. We refer to a service as application software in an information system, which of-

fers a specific set of functions to users by a provider through a communications net-work. [4]. It fulfils a special purpose for the user abstracting from the pure system

SAP, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, [email protected]

Abstract. Ubiquitous networks and seamless terminals are potential efor session mobility and session transfer. In a business environment, smobility is restricted by the security requirements set forth by corporatrity policies to protect corporate assets. Session mobility can be suppothe extent that specified corporate assets are still protected even thoughsion is transferred to another mobile device. We describe a policy-drivproach for secure session transfers. Secure session transfer mechanisms vwhether or not a session transfer is allowed, establish secure interactionnels with target devices, perform security context negotiation and, if all ous steps are successful, facilitate transferring a session from a source toget device. The protocol is supported by security policies and digitally sassertion tokens. Policies define the constraints to be met bef

1 Introduction

Ubiquitous networks can be identified by the following properties [6]: − Seamless wireless access: users can receive services of desired grade

ual basis, without worrying about the differences in wireless access systems.− Seamless terminal: users can receive services on a continual basis through th

suitable terminal according to time, place, preferences and other conditions. Seamless wireless access enables intra- and inter-technology transfers, e.g.

fers between WLAN access points (intra-technology) as well as between WLAGSM/3G networks (inter-technology). Seamless access paired with ubiquitousmunications establishes a computing platform where users can select from a chodevices and can experience services tailored to their specific needs and for beformance (= seamless terminal). Seamless wireless access, ubiquitous commtions and seamless terminal together are required to support service mobility, i.

capabilities. A session describes the meaningful context of one executed servicthe coordination of all tasks and information that are common to all processeservice execution [5]. Session mobility refers to the transfer of a session frsource mobile device to another, target mobile device(s); session transfer is thcedure implementing session mobility [9]. As an example of a session and stransfer, one may think of a mobile worker who starts a business task on a PDdecides to transfer the running business task to his or her laptop for more convp

e, i.e., s of a

om the e pro-ession A and enient red in

nd se-ing to

tems, a com-to re-

d may , for

minis- sepa-plica-) and

sed on ation,

er ses-that

uthor-cation curity quired

n es are er, the of the

ct the policy (this may include routine ith an gram-

s. Our ecked curity licies,

e resultant security constraints are negotiated with the target mobile device. The described secure session transfer is instrumented by specific security policies and employs signed message tokens for proof of assertions and integrity. All elements are integrated into a prototypical software framework, which contributes the following concepts:

rocessing of large spreadsheets or text documents. Such scenarios were explothe Witness project [11], to which the authors contributed.

While today there have been many advanced systems that support network acurity administrators in - even remotely - configuring, monitoring and respondchanges in the security environment of extensive networked information syscommon problem they face with mobility is the capability of users to workpletely offline with respect to the central domain controller. Users may need motely connect to the information system over insecure public networks, analso use intermediary and auxiliary devices, for transferring sessions to themsupporting their work, which are outside of the control range of the system adtrators. In addition, as developers and system administrators normally work inrate departments and phases of system development, there is no coupling of aption functionality (including the mechanisms for transfer of the functionalitysecurity enforcement. Utilizing this decoupling by local policy enforcement bathe enforcement of security policies prescribed by the central, remote administrwe therefore sought to specify and implement a realistic mechanism to transfsions that still allows users the freedom of mobility yet assures administrators application sessions continue to be secured.

Corporate assets should be protected against threats such as disclosure, unaized modification and loss due to physical theft of device, unattended applisessions and breaches in communications integrity. Provision of respective seservices and mechanisms is done by corporations in order to achieve the redegree of protection. The degree of protection and security measures are defined ienterprise security policies. With each of mentioned elements, security servicassociated and utilized in the enterprise network and on mobile devices. Howevenforcement of these policies is still dependent on the diligence and due carehuman end-users, who in many cases neglethings such as “frequently download operating system updates”), such that wapplication capability such as session transfer, the need for an enterprise to promatically mitigate end-user interactions is critical.

In this paper we define a policy-driven approach for secure session transfersession transfer protocol is outlined as follows: first, security policies are chwhether a session transfer can be allowed or not. Second, the applicable seconstraints for the session are determined as expressed in terms of security powhile th

− A framework where security requirements are derived from the needs of business

hanisms for negotiation of security constraints between source and target de-

e f secure session transfer in a flexible manner by taking security

n sig-es the ed. In

placing the focus on the steps of the session transfer protocol that specifically deal with poli-cies, security requirements and security negotiation.

plica- proc-on as iables rature .g. in e data ion of

Initia- ways

introduced. It is mainly concerned with signalling for the o one of the

fer of ith an ne de-to-end

ess to curity self, it ll as it

does not deal with security requirements of the session itself. Ponder [14] is a mature platform for policy research, including topics such as

specification, deployment, refinement and enforcement. Many policy-related projects and frameworks, including WiTness, have done a specialization of the basic policies

applications; − Mec

vices; − The establishment of secure interaction channels for exchange of session stat− The performance o

policies into account. The paper proceeds with Section 2, which identifies related work on sessio

nalling and session transfer, as well as security policy work. Section 3 describassumptions and environment within which secure session transfer is completSection 4 we provide an in-depth description of our session transfer protocol,

2 Background and Related work

A session can be determined as the “meaningful context of one executed aption, i.e., the coordination of all tasks and information that are common to allesses of one application execution” [5] or in terms of [3], we understand sessithe state of an application process which is given by data structures and varneeded. In addition to these process-oriented definitions, we find in the litedefinitions that motivate a session by considering communication services; e[10], a session is defined as “a set of multimedia senders and receivers and thstreams flowing from senders to receivers”. In this paper we use the first definitsession as our main reference.

There is a range of work in the area of session transfer; The IETF Session tion Protocol (SIP) [13] is basis for some approaches like in [12] where threefor a session transfer aretransfer of streaming sessions from one device to another: the data stream tdevice is interrupted and sent to the new device. It does not preserve the state application and transfers it.

The iMASH [2] architecture, on the other hand, is concerned with the transan application state. It is a middleware approach to support session transfer wApplication Server (AS) that is responsible for transferring the session from ovice to another. A security architecture [3] has been defined that supports end-security through encrypting data at or above transport layer during session transfer. Furthermore authentication and authorisation are introduced to control the acciMASH devices. This architecture is an improvement to other approaches as seconsiderations are taken into account. Although it secures the session transfer itlacks the flexibility of our security policy-driven session transfer protocol as we

defined within the Ponder framework. The basic security-related policies aAuthorisation-Policy, which specifies what operations a subject is allowed to peon an object, and the Obligation-Policy, which specifies what operations a smust perform on an object as a management duty. Subtypes of these base claspolicies include delegation, restraint and trust. Following the WiTness approacsecurity policies are described at a lower level and the framework develope

re the rform ubject ses of h, the

d with the s. ed by e syn-ftware y con-

ices, such that a consistent set of security services and mechanisms can be invoked on the target device, consistent with the security services and mechanisms on the source device.

gure and a viron-

public (4) the

ntrols, and (5) the target appli-cation servers complete the central update and submission of the synchronized trans-action, in what we refer to as the “enterprise environment”.

expectation that the environment consists of heterogeneous devices and networkA system for specifying, interpreting and invoking the mechanisms referenc

security policies underlies our proposed solution. Given a machine-interpretabltax, policies are precisely specified and can be enforced by a supporting soframework. Enforcement in the context of session transfer implies that securitstraints (defined by security policies) can be negotiated between mobile dev

3 Mobile business and foundations of secure session transfer

Consider a mobile business application using the network configuration in Fi1, (1) where a session transfer is synchronized between an auxiliary device mobile device over a wireless network, in what we refer to as the “visitor enment”, (2) a local preparation of the data is done on the mobile device, (3) anetwork provider is used for contacting the corporate information system, corporate network enforces its network-level access co

Public Network(Internet)

Corporate Information Systemnt)

(Visitor Environment)

targetdevice

mobiledevice public

routerMobile Usernetwork

corporateproxy/firewall

networkgateway

applicationservers1

2

3 3

4

45

wireless networking (WLAN)

(Enterprise EnvironmeFigure 1: A typical networking infrastructure for mobile business application, showing tion decision poin

interac-ts (1) to (5).

nication be ac-

The interaction decision points (3), (4) and (5) are therefore essentially handled by the state of the art in security management technology. However addressing the un-certainties of interaction decisions in the visitor environment - i.e. interaction decision points (1) and (2) - remain a challenge for administrators in terms of specification and

An interaction decision point is a set of rules that determine if interaction/commu

with an identified principal (based on e.g. IP-address, content, credential, …) should cepted or revoked.

enforcement. These are therefore the focus of the secure session transfer architecture and protocol.

3.1 Towards Secure Session transfer

secure ework sed as

in-ation system

ica-rating system (e.g. a virtual machine)

pplica-

p-ication.

ing to g. locale, current user, processes…

w the

tween ing a secure session transfer, prior to trans-

mission of the session to the target/ auxiliary device. This order of events is depicted in Figure 2 and subsequently outlined:

As a starting point for designing the architecture of the support system for session transfer, we first made some assumptions, based on the WiTness fram[11], about what should be available on the source device. These are summarithe following:

Mobile Application (MAP): the mobile application software that has beenstalled by an administrator of the corporate inform

Application Manager (APM): trusted module that intermediates between appltions and the ope

Application Data Store (ADS): a local database or file store accessible to ations via the APM

Security Module (SEC): a library of cryptographic functions and utilities that suport encryption/decryption, signing and verification of tokens, and authent

System Properties (SYS): a dataset of modifiable system properties referrattributes of the device and its environment e.

Communications (COM): a set of network protocols and interfaces that allodevice to at least communicate over a short range

Additionally, we define a particular order of internal event-interactions bethese components within a device execut

MAPADS

COM

user interface

SYS

12

34

56

8

MAP: Mobile APplicationAPM: APplication MangerADS: Application Data StoreSEC: SECurity moduleSYS: SYStem propertiesCOM: COMmunications

SEC APM

7 9 10auxiliarydevice

1

Figure 2: Desired module and interaction diagram for interaction between modules in a ing secure session transfer.

device invok

ty and

signals the APM with the property required of the target auxiliary device. It is possible that an auxiliary device publishes its availability to the APM as well as part of a discovery process.

2. MAP requests the APM to gather the relevant application data for the session transfer based on a data-query

1. MAP initiates session transfer by specification of application functionalidata to be transferred, and

3. evice . This is done by the SEC, based on both

4. the data elements in the ADS, allowing the

requested application data

ay proceed with the ap-

makes a final configuration decision before initiating the transfer nsfers

ior to “target should emen-

vel secure interac-tion specification, supporting negotiation between the source and target, as well as confirmation that the target is compatible with the source’s specification.

s and ay be igura-“mas-esting sts) or ervice ession sions.

o-eed to epted rning

d to be d with

are ploy-

envi-ronment, they may share applications and rights to certain services or data. The poli-cies governing how these rights are shared between principals are referred to as “delegation policies”. These may also be encoded in the tokens – named authorization certificates – in terms of constraints on role interactions and number of delegations.

APM must first check the access to the application data by the current duser and the target auxiliary deviceuser and system credentials/ properties

The SEC can then permit access to APM or user to validate before transfer

5. The ADS then locates and collects the6. Sensitive application data is encapsulated 7. The SEC informs the APM that the session transfer m

propriate security settings 8. The SYS provides the current system properties to the APM 9. The APM10. The COM establishes a secure channel with the auxiliary device and tra

the session Up to this point we have outlined what must occur on a “source device” pr

secure session transfer. Attention is now given to the interaction with the device” at the receiving end of the session transfer. Although each device contain the modules defined above, there can be no assumption about their impltation details. It is therefore desirable to have a means of higher-le

4. Extending session transfer with security policies

Considering the above networking infrastructure, operational assumptionfunctional goals, we have identified four types of security policies, which mconsidered in security administration procedures: these are authorization, conftion, delegation and federation policies. An authorization policy is generally a ter policy” controlling access to network resources based on a claim by a requprincipal. These policies are typically specified using ACLs (Access Control LiRole-based Permissions, or may be dynamically adjusted based on SLAs (SLevel Agreements). A principal may then claim authorization by proving possof a verifiable token containing the accepted attributes in the ACL or permisThe standards for generating, distributing, signing, verifying and revoking these tkens are a decision made by the system administration. There is therefore a nconfigure all concerned machines with the appropriate utilities based on the accattributes and mechanisms. We have termed the set of rules and constraints govethe installation of a device as a “configuration policy”, such that it is considerea derivative of the authorization policy. Configuration may also be concerneutilities that monitor the environment within which claims to system integrity made, which is an additional attribute of authorization/trust. Furthermore, as emees, business partners and customers tend to interact outside of the enterprise

There is therefore a recursive validation incurred, in that a delegate must still haappropriate authorizations before being delegated. Finally, delegation is in mosmore than the sharing of an application or device; it may include the interconnof devices (similar to Figure 1), an assumed technical capability for session trasuch that the properties of a delegate or federated device also need to be proveconstraints on this device interconnection are referred to as a federation policythat there is a further logical dependency between configuration, delegation aneration. Figure 2 shows what we refer to as the “policy constraint chain”, showiconstraint dependencies enforced between differe

ve the t cases ection nsfer,

n. The , such d fed-ng the

nt policy types and the subsequent s (*) that a requester will make based on a policy.

claim

Roles,SLAs,

PermissionsAuthorization

Policy

ConfigurationPolicy

DelegationPolicy

FederationPolicy

Corporate Information SystemMobile User

auxiliaryice

a bc e*

d*

c*b*a*

devd e

Figure 3: Security policy decision constraints. {a, b, c, d, e} are a set of policy-basstraints while {a*,…,e*} is the set of corresponding policy claims.

As mentioned previously, there is an assumed trust between the corporate inftion system, subsystems, employees and administrators within the physical bories of the enterprise environment. Therefore, we do not place focus on how azations are specified or enfo

ed con-

orma-unda-

uthori-rced, in that systems and standards in that area are mature

and increasingly dependable. Our focus remains with enforcing the constraints c, d, e and handling their respective claims c*, d*, e*, which are required in order to com-

laims. a mo-site is nother ere is

from Emp#1 to Emp#2. Emp#2 also decides to use the large screen available at the remote site in order to enhance the presentation. However, there are certain elements of product data that should not be transferred to the large screen. A policy-specification language has therefore been defined for allowing an administrator in the corporate

plete a secure session transfer.

4.1 Policy and token specification

Policies are specified rules of interaction while tokens are used to encode cTo make the utility of the policies and tokens clearer, an example scenario of bile employee (Emp#1) making a presentation of a new product at a remote used. Emp#1 becomes ill and decides at the last minute to delegate the task to aemployee (Emp#2), who is coincidentally also present at the remote site. Thcurrently no connection to the corporate network, such that the presentation and product data can only be transferred using a short-range wireless connection

domain to specify these interaction rules, which only allows the interaction to proceed when the conformant claims/ tokens are supplied.

A single policy-template has been defined for all policies in order to keep terational semantics simple. The policy specifications vary based on the type, naConfiguration “C”, Delegation “D” or Federation “F”. A similar approach wawhen describing the assertion tokens, used

he op-mely:

s taken as the mechanism of policy-compliance-

proof within the secure session transfer protocol.

pec d e ena

YPE eration)

Table 1: Policy s ification template an xample based on sc rio

POLICY-T “C”(Configuration “D”(Delegation) “F”(Fed)

POLICY-ID identifi ng t icy A unique er for distinguishi he particular polSOURCE Application or data User identifier Device identifier TARGET Application User identifier Device identifier ACTIVITY “read, write, delete, update…” SCOPE Config. constraints Role constraint Platform constraint ASSERTIONS Proof of role Proof of platform Proof of config ATTEMPTS an be made Number of times policy claims cLIFE piry daTIME Ex te of policy SIGNATURE Signature of policy creator and issuer * POLICY-TYPE: "C"; POLICY-ID: "C-ProductPresentation"; SOURCE: "ProductDB"; TARGET: "Presentation"; ACTIVITY: "read,write,view"; SCOPE: "Secured"; ASSERTIONS: {specified-crypto-suite}; ATTEMPTS: "2"; LIFETIME: "01122004"; SIGNATURE: sign(Co , hmpany.Priv ash(FEmp1)). * POLICY-TYPE: "D"; POLICY-ID: "D-Emp1"; SOURCE: "Employees"; : "Employees";TARGET ACTIVITY: "read, write, modify "; SCOPE: "Management"; ASSERTIONS: {Emp-token}; ATTEMPTS: "2"; LIFETIME: "01122004"; SIGNATURE: sign(Company.Priv, hash(D-Emp1)). * POLICY-TYPE:"F"; POLICY-ID:"F-Presentation"; SOURCE: "PDA001"; TARGET: "Any"; ACTIVITY: "read, write"; SCOPE: "Trusted"; ASSERTIONS: {Attestation-Key}; ATTEMPTS:"2"; LIFETIME: "01122004"; SIGNATURE: sign(Company.PrivateKey, hash(F-Emp1)).

Trust certificates define properties of a mobile device, e.g. its owner. These prop-

erties are evaluated against the constraints in the federation policy. Trust in a mobile device is established because the device is owned by the same administration or is owned by another administrative organization with an established trust relationship, i.e. cross-certification.

Table 2: Token specification and example based on scenario

atio trust TOKEN-TYPE “AUTH”: Authoriz n “TRUST”: DeviceTOKEN-HOLDER fier Primary user identifier Primary device identiTOKEN-ISSUER oration

er controller

or device manufacturer Trusted corp – Trusted domain typically employ

TOKEN-VALIDITY Expiry date of token TOKEN-ASSERTIONS User capability claim Device capability claim SIGNED User assertion confirm Device assertion confirm * Token-Type: "AUTH"; Token-Holder: Emp#2.PubKey; Token-Issuer: Company.PubKey; Token-Validity: 31122004; Token-Assertions: "General Management"; Signed: sign(Company.PrivKey, hash(Emp#2.PubKey)). * Token-Type: "TRUST"; Token-Holder: Laptop002.AttestationKey Token-Issuer: Manufacturer.PubKey; Token-Validity: 31122004 Token-Assertions: "Trusted"; Signed: sign(Manufacturer.PrivKey, hash(Laptop002.)).

4.2 Secure Session Transfer Protocol and Security Context

The session transfer protocol is message-based, allowing low coupling between source and target device. We also introduce the additional assumption that the and source have exchanged a lower level session key for full encapsulation packets including headers and payload. The objective of the protocol is to bring tsource and target to agreement, such that the claims made by the target correwith constraints specified within the source’s federation and delegation policierefer to the process of coming to agreement as “security context negotiation.”rity context negotiation consists of several steps (see Figure 4), given that the certificate of the target device has already been checked. If the target devicetrusted (based on an unavai

the target of the

he spond s. We

Secu-trust

is un-lable token) no further negotiation occurs and the session

transfer is cancelled. Table 3 below contains a description of payload (contents) of urce and target device during the nego-

urity contex

Table 3: Message types for s

the message types exchanged between the sotiation of the sec t.

ecurity context negotiation

Message Type Payload description SESSION_OBLIGATIO ob-

must st for

s the poli-

the source.

N Originates at the session source. Specifies theligations that a target must do or attributes thatbe possessed, in order to qualify as a valid hothe application session. The payload iASSERTIONS of the federation and delegationcies associated with the application running on

SESSION_ SECURITY_ NEGOTIATION

Originates at the session target as a response to an obligation, which cannot be fulfilled by the target under the conditions proposed by the source. The

payload states that a negotiation about the security constraints is necessary.

SESSION_

POSSIBILITIES

nego-s con-

trans-arget pay-

at the .

SECURITY_ Originates at the source as a response to a

tiation message from the target, based on itfiguration. The payload contains a listing of TOKEN-ASSERTIONS that the source will accept for thefer of the session. It is also a response from the tto the same message from the source where theload contains a listing of constraint terms thtarget can support for the transfer of the session

SESSION_CONFIRM Originates as a confirmation from the target that it can perform the obligations specified by the source. In this case the payload contains the target’s proof that it can perform these obligations. The message type is also used by the source as an acknowledge-ment and acceptance of a target as a session host. In this case the payload contains the serialized session binary and user data.

This message is sent by either the source or when it is noticed that a stage in th

SESSION_DISABLE target e negotiation

process has been reached and no further possibilities exist. The session transfer is then terminated

In Case 1 of Figure 4, the target device could not make the appropriate clai

have the capability of suppoms to

rting the security context, while in Case 2 the secure session transfer is disabled, as the source device doesn’t agree with the possible capa-

et device.

h com-efines nner,

nditions whether a session transfer is allowed or not, it estab-ontext from

sfer is okens ay be

target of a session transfer. Our session transfer protocol extends current session transfer protocols by explic-

itly dealing with security constraints. Not only to secure the session transfer itself (which is done in our framework as well) but additionally checking security con-

bilities sent by the targ

5. Conclusions

We have described an approach for a secure session transfer. The approacprises respective system architecture and framework as well as a protocol that dthe different steps of the session transfer. Session transfer is done in a secure mai.e. it validates the colishes protected communication links to target devices, it performs security cnegotiation and, if all previous steps are successful, it transfers the sessionsource to target device.

The protocol is semantically supported by security policies and verifiable tokens. The former define the constraints to be met before (i.e. decision whether tranpossible or not) and after session transfer (i.e. respective security context.). Tare utilized to claim attributes of suitable trustworthy mobile devices, which m

straints of the service or application. Our motivation to look into security rements of services and applications is driven by the specific usage s

quire-cenario we are

ng on: mobile business applications where security is a vital element.

focussi

Figure 4: Security Context Negotiation activity diagram

Although our proposed session transfer protocol provides for a transfer ainstallation of the session state as well, this is not a prerequisite. If a scenario dorequire an explic

nd re-es not

it state transfer our protocol is equally applicable: it performs an evaluation of security policies, identifies feasible mobile devices, performs a security context negotiation and does the session transfer by terminating the session on source and re-starting the session on target mobile device. This could be likened to a secure session-replication.

In the paper it is assumed that source and target device support the framewdescribed before. Therefore a challenging task is to support devices not haviframework. For this support a translation mechanism between the different detions of security properties is necessary. To indicate which translation m

ork as ng this

scrip-echanism is

needed the SESSION_SECURITY_NEGOTIATION message can be extended.

References

ibuted national and Interdisciplinary Conference on

igence

. Cheng et al.: iMASH: Interactive Mobile Application s, and

tecture for Application Session ), April 28 - May 2, 2002.

cover

28, May

Aspect of Application Security Management, arch 2004.

echni-

ol, IETF RFC 2327, April 1998. binson:

chitecture and Implementation, In-

Com-

for the Ponder Language, IFIP/IEEE Symposium on Integrated Network Management, Seattle, USA, 2001.

15. L. Bussard, Y. Roudier, R. Kilian-Kehr, S. Crosta: Trust and Authorization in Pervasive B2E Scenarios, 6th Information Security Conference, Bristol, UK, October 2003.

1. G. Kouadri Mostéfaoui, P. Brézillon: A Generic Framework for Context-Based DistrAuthorizations, Proceedings of the Fourth InterModeling and Using Context (CONTEXT’03), Lecture Notes in Artificial Intell2680, Stanford, California (USA), June 23-25, 2003

2. R. Bagrodia, S. Bhattacharyya, FSession Handoff, ACM International Conference on Mobile Systems, ApplicationServices (MobiSys '03), May 2003.

3. E. Skow, J. Kong, T. Phan, F. Cheng et al.: A Security ArchiHandoff, International Conference on Communications (ICC 2002

4. ITU-T Recommendation X.511: Abstract Service Definition, 1993. 5. H. Berndt, et al.: The TINA Book, Prentice Hall Europe, London, 1999. 6. NTT DoCoMo: All-IP Mobile Network Platform supporting a Ubiquitous Society –

page, NTT DoCoMo Technical Journal, Volume 4, Number 4, March 2003. 7. R. Shirey: Internet Security Glossary, IETF International Request for Comments 28

2000. 8. P. Robinson, M. Rits, R. Kilian-Kehr: An

AOSD Workshop on Application-level security (AOSDSEC), Lancaster, UK, M9. S. Thakolsri, W. Kellerer: Application-layer mobility, DoCoMo Euro-Labs Internal T

cal Report, January 2004. 10. M. Handley, V. Jacobson: Session Definition Protoc11. T. Walter, L. Bussard, Y. Roudier, J. Haller, R. Kilian-Kehr, J. Posegga, P. Ro

Secure Mobile Business Applications – Framework, Arformation Security Technical Report, Vol. 9, No. 4, 2004.

12. H. Schulzrinne, E. Wedlund: Application-Layer Mobility Using SIP, ACM Mobileputing and Communications Review, Vol. 4, No. 3, July 2000.

13. J. Rosenberg, et al.: SIP: Session Initiation Protocol, IETF RFC3261, June 2002. 14. N. Dulay, E. Lupu, M. Sloman and N. Damianou: A Policy Deployment Model