with
each
other.
Beside
jkjkjkjjkjk
Charging relatedinP-based mobile Device Authentication Anonymous Connections Architectures for Mobile Communication Dirk Westhoff1), Bernd Lamparter2) 1,2)
NEC Europe Mobile Internet Group*
Adenauerplatz 6, D-69115 Heidelberg, Germany NEC Europe E-mail:{dirk.westhoff, Mobile Communication bernd.lamparter}@ccrle.nec.de Group1 Heidelberg, Germany
Abstract: In the context of Mobile IP, authentication, authorization and accounting (AAA) is a challenging problem. Current Mobile IP deployments typically do not span trust boundaries, because there has not been any clear agreement about how network administrators from unrelated enterprises could agree upon to assure mutual security, and compensate each other for resource utilization, when enabling connections for mobile computers. AAA addresses this problem. We propose and evaluate various schemes and protocols to authenticate a mobile node in the context of Mobile IP/AAA. Their suitability depends on the assumed mobility scenario as well as it strongly depends on the purposes of the assumed accounting scenario. E.g., the requirements to an integrated AAA framework differ significantly when different business models with different charging schemes are deployed. Pre- or post-paid business models have completely different requirements for an authentication scheme/protocol than fixed contract business models. Keywords: Authentication, Mobility, AAA
1. Introduction The Mobile IP (MIP) protocol is an IETF standard providing transparent routing solutions for host mobility between IP domains while maintaining transport-level connections. In case MIP shall be used over different administrative domains further protocols for resource usage agreements between the involved domains are necessary. AAA tries to address this problem. Its terms are defined [1], [2] as follows: Authentication - the act of verifying a claimed identity, in the form of a pre-existing label of a mutually known
name space, as the originator of a message or as the endpoint of a channel. Authorization - the act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential. Accounting - the act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation. Authentication, authorization, and accounting partially are interdependent. Authorization typically bases on authentication whereas some purposes of accounting typically base on authentication and authorization. On the other hand, for choosing an appropriate scheme/protocol to authenticate a mobile host in a foreign administrative domain, we have to focus on particular accountingscenarios. Is accounting mainly used for trend analysis and cost allocation? Which of the involved parties should trust each other? What are the flow directions of billing and payment between the involved subscribers and their service providers? What are the assumed cost and pricing models for Internet access? What is the business policy in case a subscriber denies having used a service? These and several other questions have to be considered before offering the ‘optimal’ authentication scheme/protocol in the context of MIP/AAA. Although some architecture work [1], [2], [3] is done and several companies like Lucent Technologies [4], Cisco [5], Nokia [6] etc. already offer products supporting AAA they do not focus on accounting dependent authentication proposed by us. Our paper intends to be a first step into this direction. It mainly focuses on different authentication forms of a mobile device. Nevertheless for supporting particular business models it may be also necessary to authenticate service requests and service
*T he NEC Europe Mobile Internet Group, Adenauerplatz 6, D -69115 Heidelberg, Germany, consists of X. P. Costa, H. Hartenstein, B. Lamparter, M. Liebsch, A. Sarma, R. Schmitz and D. Westhoff. Corresponding author is D. Westhoff,
[email protected] , Tel. +49/(0)6221/13708-20.
usage as well. In addition, beside authenticating the mobile device it may be also necessary to authenticate its user. The remainder of this paper is organized as follows. In section 2 we point out characteristics of various authentication schemes/protocols as well as for its underlying security infrastructure. Section 3 sketches accounting purposes whereas in section 4 we present authentication protocols that variously weight on particular accounting purposes. Section 5 concludes and gives an outlook.
as well. E.g., the Global System for Mobile Communication (GSM) [8] uses such a protocol for authenticating the subscribers’ identities. When the subscriber is added to its home net for the first time, an initial long-term key is assigned to the subscribers global identifier. The key is stored on the subscribers’ SIMCard as well as on the net side. For authenticating the subscriber, both sides compute on the initial key and on a random number (challenge) a signature (response). Such an authentication protocol is repudiative.
2.2. Unique versus Separate Name Spaces
2. Authentication 2.1. Schemes and Protocols Applied cryptography [7] offers two fundamental different schemes for authenticating the sender of a message. The first method bases on using a Message Authentication Code (MAC), whereas the second is using a digital signature. Both methods establish that the received data was generated by a specific party at some time in the past. This is known as data origin authentication. A MAC bases on a keyed hash function hk (x) over a message x using a secret key k. A party receiving x, h k (x), separates x from h k(x), computes h k(x) on the received data and the shared key k and compares its own with the received MAC. A digital signature bases on an un-keyed hash function h(x). In almost all approaches implementing digital signatures sender and receiver use an asymmetrical scheme E. The sender owns a private key ps and the receiver knows the corresponding public key es. A party receiving x,Eps{h(x)}, separates x from Eps{h(x)}, computes h(x) on x and compares the result with Ees{Eps{(x)}}.1 Both schemes serve to check data integrity and origin authentication. Nevertheless, their features are substantially different. Using a MAC, in case of a positive check, the receiver doubtless detects the sender as the originator of a message. A third party, even when knowing k, would have no chance to decide if data is descended from the sender or the receiver. This authentication mechanism is called repudiative. In contrast, using a digital signature and assuming that a third party knows the public key es, this party is able to proof the originator of the message. This mechanism is called non-repudiative. Beside the mentioned schemes for data origin authentication challenge-response protocols authenticate 1
This description strongly relates to the usage of RSA.
Data origin authentication, the act of verifying a claimed identity as the originator of a message, requires the inference from a pair consisting of key and name to an identity. Although a definition of the term identity is behind the scope of this document it should be clear that such a definition is a fuzzy one. It may involve the distinguishing character of the individual and/or memories between the originator of a message and the verifier. Knowing that this is a simplifying view to the problem, we assume that an individual’s name resp. identifier is a label for its identity. In case originator and verifier are part of the same administrative domain we can assume that they belong to and know about the same local name space. Being aware of the binding of the originator’s key to its name, the verifier may infer to the originator’s identity. If the binding of key and name is explicit by using a certificate under a unique name space, this certificate is called identity certificate. In case originator and verifier belong to different administrative domains, even assuming a known certificate, by not knowing the originator’s name, the verifier cannot infer the originator’s identity. [9] proposes to establish authorization certificates whereas [10] favors delegation certificates. The authors argue that, if the involved parties do not know their names because they belong to different name spaces, inference of the originator’s identity is not possible. Even when using a global unique name e.g., the Network Access Identifier (NAI) [11], it is clear that there is no universal, global name space with meaningful names to all possible users. In [9] a local identity certificate becomes a global authorization certificate. Such a certificate binds a key to a name that is not necessarily part of the verifier’s name space. In [10] the view of the world is key-oriented and the originator’s name is fully ignored. A delegation certificate is a signed message with which an issuer grants access rights that it has to another entity. For both approaches the verifier’s authentication check in combination with
such certificates does not reveal the sender’s identity. Nevertheless they may serve a foreign originator as credential for acting in a particular manner on the verifier’s resources.
credit to the provider, whereas in a post-paid scenario the trust credit would be vice versa. Appropriate authentication mechanisms may help to reduce such trust credits.
3. Accounting 4. Accounting, the act of collecting information on resource usage dynamically monitors resources, either host-, network-, or service-based. It supports auditing for cost allocation, price calculation [12], [13] and charging: Cost allocation for network usage considers the availability of non-storable network capacities as well as the architecture’s characteristic of high fixed costs and low variable costs. Whereas fixed costs can be allocated independently from a mobile’s access to a network, the variable costs depend on the mobile’s service usage for different service classes and have to be calculated a posteriori or at runtime by minimizing its own performance overhead. Price calculation often uses the results of cost allocation and tries to optimize the network provider’s profit by sometimes also providing feedback signals to the subscribers purposing on the overall welfare. The resulting charging schemes are mainly flat-feebased or usage-based. The first schemes focus on the high fixed costs of the network and sometimes include an average amount for overall services to handle variable costs, where the latter in particular also pay attention to special service request or service usage dependent variable costs. They may be calculated on time -, volumeor QoS-base. Fees often support special tariffs (e.g. night, day, weekend) and provide feedback signals to subscribers partly influencing demand and usage. Depending on the charging scheme different types of authentication seem to be necessary. We distinguish between the following three basic charging schemes: In case the charging scheme is flat-fee-based, the mobile device does not necessarily need to be identified, neither by the foreign domain nor by its home domain. Payment may be pre- or post-paid. In case the charging scheme is usage-based we have to separate pre - and post-paid business models. In a pre-paid scenario the authentication mechanism shall support an authorization mechanism that serves to deny noncontractual assured services whereas in a post-paid charging scheme an authentication mechanism mainly serves to doubtless detect the mobile devices’ accesses and its service usage. Without any kind of authentication in a pre-paid scenario for the duration of a charging period the owner of a mobile device would give a forward trust
Authentication for Accounting
4.1. Framework [1], [3], [14], propose AAA requirements for Mobile IP. In case the mobile host accesses a foreign administrative domain, for authentication a control flow of a mobile’s credential from the mobile node (MN) to a foreign domain’s service interface called Attendant (A), to the foreign AAAServer (AAAF) and from there to its home AAAServer (AAAH) is required. Beside security associations between AAAH and MN, A and AAAF as well as between AAAH and AAAF 2 the proposals implicitly assume three different name spaces (fig. 1).
MN
A AAAH
AAAF
Figure 1: Three different name spaces in the context of MIP/AAA. The proposals neither describe the form of an MN’s credential nor the moment and/or location of its verification. By integrating the presented authentication schemes/protocols of section 2 into the MIP/AAA architecture, we offer various approaches for content, moment and location of verification of credentials aiming to different accounting scenarios and trust models. foreign provider
home provider
subscriber
billing payment
2
For scalability reason and in case the foreign provider does not trust the paying ethics of the home provider, the proposals introduce a trusted third party, named AAABroker.
Figure 2: Billing and payment flow. We solely assume a billing and payment scenario where the billing flow is directed from the foreign provider over the home provider to the subscriber and the payment flow is vice versa (fig. 2). If necessary such a model may be extended to billing and payment chains between several providers. We further assume MN and AAAF having exchanged a secret session-key to guarantee a confidential channel as well as between AAAF and AAAH. All protocol data are therefore sent in a ciphered form.
4.2. Time -shifted Subscriber Charging The following three protocols, for reason of minimizing latencies in a perhaps time critical mobile communication scenario, do not involve AAAH to authenticate MN at the moment it accesses to a foreign network. If contacting, they contact AAAH at the end of a charging period. Within the second protocol AAAF offers a forward service credit to the accessing foreign subscribers. Not involving AAAH at runtime is useful in mobility scenarios where the focus is on continual services, MN’s frequency of attachment is relatively high and/or there is a large number of different providers.
4.2.1.
MAC-based Authentication
Against all laws of the market, this protocol purposes on a simple charging scheme with flat-fees from AAAF to AAAH as well as from AAAH to MN. Authentication does not influence the current fees and is solely used for trend analysis and cost allocation. Both may be necessary to check if the demanded fees are still profitable. Fees have to be pre-paid. In such a scenario it is neither necessary to know a subscriber’s identity nor to authenticate her in a non-repudiative way. It is even not necessary to analyze the assumed trust model. If the involved parties do not trust each other, fees are constant and regulated by contracts.
(2b) type(x)?=valid frame (3) AAAF -> A: foreign or home id
In case trend analysis and cost allocation beside some quality of service parameters solely base on the number of subscribers’ network accesses, a MAC that does not need any kind of security infrastructure may be an appropriate scheme. To prevent a subscriber having access to the foreign network without having paid the flat-fee in advance one may use a temporary secret x that is revealed to the subscriber when paying its flat-fee. Such a temporary secret may fit into a particular valid frame that has to be known by every AAAServer. This insecure approach which does neither reveal the subscriber’s identity to AAAF nor to AAAH may be reasonable under the constraints of small flat-fees for subscribers and short guilty periods for the valid frames. A forwards the credential to AAAF (1)-(2), AAAF checks the integrity of the credential (2a) and proofs if it fits into the frame (2b). Afterwards it sends the result to A (3)(or a gateway controlling the subscribers’ access). In particular it is possible for AAAF to check data integrity of x and whether the subscriber belongs to the home administrative domain or, in case of an unknown identity, it belongs to an unknown foreign domain. Unfortunately AAAF has no chance to doubtless split up foreign subscriber accesses to foreign domains. Another disadvantage is the fact that instead of a security infrastructure this approach needs an infrastructure that guarantees subscribers to buy temporary secrets as well as AAAServers to proof their valid frame.
4.2.2.
Digital Signature and Authorization Certificate
Purposing on a usage-based and post-paid charging scheme for AAAH as well as for its subscribers that beside some service parameters bases on the foreign subscribers’ accesses and their repeating behavior, we may use digital signatures and authorization certificates. Digital Signature and Authorization Certificate (1) MN->A:
MAC-based (1) MN -> A:
(2a) hk(x)?=hk (x)
x, hk (x)
(2) A -> AAAF: x, hk (x)
cert(eMN),x,EpMN{h(x)}
(2) A ->AAAF: cert(eMN),x,EpMN{h(x)} Verification at AAAF: (2a) EeMN{EpMN{h(,eMN)}}
Verification at AAAF: (3) AAAF -> A:
foreign or home id
Concatenated to MN’s public key and a digital signature on the whole credential, MN sends an authorization certificate cert(eMN) of its public key, generated by an authorized center of its home domain (1). If AAAF (and A) receives such credentials (2)-(3) it is aware of foreign but constant subscriber identities as well as it can assign them to different foreign administrative domains. Without being aware of the subscribers’ identities, AAAF is able to calculate and collect subscriber related fees for AAAH. Knowing cert(eMN), AAAF may doubtless infer to the involved AAAH. After a certain period it may send a charging record to AAAH that is keyed per subscriber. Belonging to the subscribers’ name space, AAAH infers to their identities and calculates subscriber usage -based fees for each individual subscriber. This protocol increases authentication performance at the moment MN accesses to the foreign network. It supports non-repudiation for subscribers. Therefore AAAH’s billing policy in case of an unwarranted billing reservation from the subscriber’s side is to insist on the payment. By modifying h(x) to h(x,r) where r is a random value known by MN and AAAH, the protocol also supports a weaker trust model wherein AAAH has not to trust AAAF. AAAF is not able anymore to maliciously extend the number of foreign subscriber accesses by simply performing replay attacks. They would be detected later on at AAAH. Additionally AAAF as the active part that makes out the bill has not to trust AAAH. Of course it has to trust the authorized center.
4.2.3.
Digital Signature and Delegation Certificate
Using a digital signature and a delegation certificate another benefit is added to those features so far mentioned in 4.2.2. In contrast to the previous protocols this one ensures that in case of an eventually noncontractual service request, AAAF immediately may deny the subscriber’s service usage. Such an authentication scheme for usage-based charging beside a post-paid modus therefore may also be used in a pre -paid modus. The idea is to map the contractual ensured service classes between AAAH and MN to delegation certificates that are stored on MN’s SIMCard. For each contractual guaranteed access right ri and the duration period [t1,t 2] of this right, MN has stored a service request x:=r i,[t1,t 2],e MN
that is signed by AAAH. When receiving such a message (2), by knowing MN’s public key, AAAF is able to proof the authority of a foreign identity to grant access.
Digital Signature and Delegation Certificate (1) MN->A:
x,EpAAAH{h(x)}
(2) A->AAAF: x,EpAAAH{h(x)} Verification at AAAF: (2a) EeAAAH{EpAAAH{h(x)}} (3) AAAF->A: foreign. const. or home id
Focusing on a post-paid solution, again AAAF may collect such delegation certificates for later sending a charging record to AAAH. The protocol may support usage-based charging related to the number of foreign subscribers’ accesses and their repeating behavior. Unfortunately in this pure version AAAF is able to perform replay attacks by multiple adding subscribers into the charging record. Again a random value r, solely known by MN and AAAH should be included into the hash value. Using a challenge-response-based authentication protocol for offering a forward service credit with a posteriori subscriber fee charging is not appropriate, because of its repudiative character.
4.3. Subscriber Charging at Runtime The authentication protocols of this subsection involve AAAH at runtime to verify a foreign subscriber’s identity. For reasons of latencies AAAH should just be involved in case of changing an administrative domain. In all cases when MN accesses to another point of the actual foreign administrative domain, AAAF should have cached some data for authenticating the subscriber. Authentication at runtime is suited for a mobility scenario where the focus is on un-continual services, MN’s frequency of attachment changes is low and/or the number of different providers is low.
4.3.1.
Challenge-Response Authentication
Within this protocol the billing policy in case of an unwarranted billing reservation from the subscriber’s side
is to not insist on the payment. It bases on a repudiative challenge-response authentication that does not need any kind of security infrastructure. A forwards MN’s credential to its AAAF (1)-(2) which sends challenge to AAAH (3). After receiving response from AAAH, AAAF compares both signatures and forwards the result to A (4)-(5). Verification is located at that domain which offers the forward service credit. For verification neither AAAF nor AAAH have to trust the opposite provider. Indeed AAAH has to trust the paying ethics of its subscribers. The protocol’s repudiative character as well as its verification location are appropriate for usage-based pre paid charging that relate to the number of a mobile’s accesses. Because of its repudiative character it is less suited in a post-paid scenario.
subscriber’s known identity. In case fees between AAAF and AAAH are volume-based and related to the number of the subscribers’ accesses and their repeating behavior, ignoring the subscribers’ identities does not weaken the protocol. Again a random value may be used to protect AAAH against replay attacks from AAAF. We dispense with presenting protocols using a MAC or digital signatures with delegation certificates involving AAAH at runtime. Within the first AAAF could not doubtless assign a subscriber to its AAAH. Delegation certificates are attractive in absence of its issuer. Involving it at runtime would make them senseless.
5. Conclusions and Open Issues Challenge-Response (1) MN -> A:
challenge,response
(2) A -> AAAF:
challenge,response
(3) AAAF -> AAAH: challenge (4) AAAH -> AAAF: response Verification at AAAH: (4a) response?=response (5) AAAF -> A:
known id
4.3.2 Digital Signature and Authorization Certificate In contrast to the previous protocol this one mainly supports usage-based post-paid charging. The provider’s billing policy in case of an unwarranted billing reservation from the subscriber’s side is to insist on the payment. Using digital signatures the provider prepares for possible jurisdiction. Digital Signature and Authorization Certificate (1) MN->A:
cert(eMN),x,EpMN{h(x)}
(2) A->AAAF:
cert(eMN),x,E pMN{h(x)}
(3) AAAF->AAAH: cert(eMN),x,E pMN{h(x)} Verification at AAAH: (3a) EeMN{EpMN{h(x)}} (4) AAAH->AAAF: known id (5) AAAF->A:
known id
AAAH is the location of verification (3) and AAAF has to trust AAAH in a sense that AAAH stands surety for the
The proposed authentication protocols for MIP/AAA were derived from a scenario-dependent analysis of wellknown cryptographic schemes/protocols. By not involving AAAH at runtime, its non-repudiative character and by even supporting denial of service in case of non-contractual service requests the authors favour at least in a time critical scenario digital signatures combined with authorization and delegation certificates. Such an authentication scheme is appropriate for post-paid usagebased charging as well as for a pre-paid one. In a time uncritical scenario choice depends on the providers’ billing policy. Using digital signatures the provider prepares for a possible jurisdiction that is attractive for usage-based post-paid charging, whereas a challenge-response based authentication should be mainly used in case of pre -paid charging. More research is necessary to propose authentication protocols that support further accounting purposes. In particular this is true when focusing on a billing and payment flow assuming that the MN is equipped with electronic coins. In such a scenario we have to investigate models supporting a direct billing and payment flow. Assuming a wireless connection between MN and A this may also effect to the choice of an appropriate authentication scheme. We have to investigate the termination of a MN’s access to foreign resources. Offering mutual authentication from MN and AAAF on used resources may be necessary.
References [1]
S. Glass, T. Hiller, C. Perkins: ‘Mobile IP AAA Requirements ’, RFC 2977, 2000.
[2]
S. Glass, T. Hiller, C. Perkins et al.: ‘Network Access AAA Evaluation Criteria’, RFC 2989, 2000.
[3]
T. Braun, Li Ru, G. Stattenberger.: ‘An AAA Architecture Extension for Providing Differentiated Services to Mobile IP Users’, 6th IEEE Symposium on Computers and Communications (ISCC 2001), Hammamet, Tunesia, July, 2001.
[4]
Lucent Technologies: ‘ORiNOCO Overview’, ftp://ftp.orinocowireless.com/pub/docs/ORINOCO/BR OCHU- RES/Orinoco.pdf.
[5]
Cisco Systems: ‘Cisco Aironet 350 Series Wireless LAN Security’, http://www.cisco.com/warp/public/cc/ pd/witc/ao350ap/prodlit/a350w_ov.htm
[6]
Nokia Corporation: ‘The Nokia Operator Wireless LAN’, http://nokia.com/press/background/pdf/OWLAN .pdf
[7]
A.J. Menezes, P.C. v. Oorshot, S.A. Vanstone,’Handbook of Applied Cryptography’, CRC Press, 1996.
[8]
J. Eberspächer, H.J Vögel, ’GSM Switching, Services and Protocols’, Wiley and Son, 1998.
[9]
C. Ellison, ’Establishing Identity Without Certification Authorities’, In Proc. 6th USENIX Security Symposium, pp. 67-76, San Jose, CA, 1996.
[10]
T. Aura, ’Distributed Access-Rights Management with Delegation Certificates’, Secure Internet Prog-gramming, Springer-Verlag, LNCS 1603, 1999, pp.211-235.
[11]
P. Callhoun, C. Perkins, ‘Mobile IP network access identifier extension for IPv4’, RFC 2794, 2000.
[12]
B. Stiller, G. Fankhauser, B. Plattner, and N. Weiler. ‘Charging and accounting for integrated internet services - state of the art, problems, and trends’. In Proc. INET '98, Geneva, Switzerland, 1998.
[13]
G. Frankenhauser, ‘A Network Architecture based on Market Principles’, Dissertation, Shaker Verlag Aachen, 2000.
[14]
C.E. Perkins, ‘Mobile IP Joins Forces with AAA’, IEEE Personal Communication, pp. 59-61, 2000.
