1
`
`The 3 “A”s: Authentication,
`Authorization, Accounting
`
`For the road travelers in the United States, especially the parents who take their children in the
`family car on the long road trips, the letters AAA stand for a peace of mind. They feel that any
`time their car breaks down, they can call the number for the American Automobile Association
`and ask for roadside assistance. Even though this book is not about that sort of AAA, the 3 “A”s
`that we talk about here, when designed properly, can bring the same peace of mind to the network
`operator and its customers. Authentication, authorization, and accounting are three important
`blocks used in the construction of a network architecture that helps protect the network operator
`and its customers from fraud, attacks, inappropriate resource management, and loss of revenue.
`In this chapter, we describe each of the “A”s in the AAA first as a separate topic, and then
`as a piece that interacts with the other “A”s in an effort to justify why all the 3 “A”s should
`be treated by the same framework and servers. At the end of the chapter, we provide a model
`for a generic AAA architecture.
`
`1.1 Authentication Concepts
`According to the dictionary, the word “authentic” refers to something that is not false, or a
`fake imitation, but is worthy of acceptance as a truth or a fact. From the times of early civili-
`zations, where people have run 26 miles only to deliver a message and then fall over and die,
`to today, when information can travel across the globe in fractions of a minute with a mouse
`click, proof of authenticity is the first thing the receiver of a message checks.
`Authentication consists of two acts: first, the act of providing proof of authenticity for the
`information that is being delivered or stored, and second, the act of verifying the proof of
`authenticity for the information that is being received or retrieved. In the early ages, an
`emperor would use his personal seal on his letters to provide assurance for the authenticity of the
`letter. The letter could then be carried by any messenger, whose identity was not important.
`The local lord would recognize the emperor seal and trust authenticity of the letter. He would
`
`AAA and Network Security for Mobile Access: Radius, Diameter, EAP, PKI and IP Mobility
`Madjid Nakhjiri and Mahsa Nakhjiri © 2005 John Wiley & Sons, Ltd
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 1 of 23
`
`

`

`2
`
`AAA and Network Security for Mobile Access
`
`break the seal, read the letter, start an attack or collect taxes accordingly. In the days of digital
`information delivery, delivering proof of authenticity is equally important but poses its own chal-
`lenges, as we will see.
`The message delivery example above presents one type of authentication problem where
`authenticity of the information is important, while the identity of the messenger is not. However,
`in most of the cases, the identity of a person we are dealing with is an important factor in
`how we handle that interaction. When we go to a bank or through customs into a new
`country, we have to show identification to prove our identity. At first, the problem of
`identification does not seem to be related to the authentication. However, when one thinks
`about the possibility of a person lying about her identity or privileges, verification of authen-
`ticity of the provided identity becomes an authentication problem as well. Stating a name is
`typically not enough for identification, while showing a sort of identification issued by a
`trusted authority typically is. The acts of providing proof and verifying the authenticity of the
`identification presented are again the two acts of authentication.
`Today, the two mentioned forms of authentications, i.e. providing information integrity
`and identity verification, are among the most fundamental security mechanisms required for
`providing access to network users and clients. In this introductory section, we provide a rela-
`tively short overview of various authentication concepts to allow the reader to understand the
`distinction between the constantly confused types of authentication. In Chapter 2, we will
`delve into more details of various authentication procedures.
`
`1.1.1 Client Authentication
`
`Client authentication means that a client wishing to gain access and connect to the network
`presents its identity along with a set of credentials. As proof of authencity for the presented
`identity. The credentials are then used by the network to verify that the identity actually belongs
`to the client.
`We intentionally used the term client, since it can be interpreted both as a device as well as
`a human user, who is a consumer of a network service. For that reason, the client authentication
`needs to be further refined into two categories: user authentication and device authentication.
`Until recently, very few network security designs made a visible distinction between user
`authentication and device authentication. In the following we will explain the reason. Tradi-
`tional architectures dealing with network access control could be divided into two categories:
`
`● Architectures accommodating users that arrive at a fixed location, such as a local area
`network with fixed devices, such as data terminals, already connected to an infrastructure.
`The user needs to use its personal credentials to log into the network through a device
`(terminal), which itself typically resides in a computer room and is trusted through its
`wired connections. A good old world college campus terminal room scenario! The student
`simply trusts the network set up by the campus, as long as the college is an accredited one
`and the terminal is not asking for credit card numbers as login credentials! In this basic
`scenario, the distinction between device and user authentication although very clear for a
`human, is not important. The device is not authenticated at all. The user credential with a
`central server is the main criterion for allowing network access to the user.
`● Architectures accommodating mobile users carrying their personal devices to gain access
`to a wide area network. A perfect example is cellular phone systems. The user registers
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 2 of 23
`
`

`

`The 3 “A”s: Authentication, Authorization, Accounting
`
`3
`
`with a cellular service provider and purchases a cellular phone that works with operator’s
`network. The operator creates a set of credentials specific for the user. The cellular phone,
`that the user carries, is then programmed with such credentials to access the network.
`Many times, the user is unaware of these credentials and the actual process of authentica-
`tion during connection establishment. The device is the entity that interacts with the
`network and presents the credentials needed to perform authentication. The idea is: since
`the user always carries the same cellular phone (as long as she is loyal to her service
`provider) no distinction between the user and device credentials has to be made. The
`downside is that if the device was lost, stolen, or even cloned, the rouge or unintended user
`could use the device to gain access to the network without having her real identity
`exposed, and this could go on until the legitimate user would report a lost or stolen phone
`or illegitimate entries in her monthly statement from the service provider.
`
`With the proliferation of public local network providers, such as wireless hot spots
`serving passing customers, many sorts of vulnerabilities will appear at various corners of
`the architecture:
`
`● The long-term customer–operator business and legal relationship no longer exists, which
`means the network operator and the user cannot trust each other as.
`● The one-to-one mapping of user–device does not exist. Even if the operator could trust a
`user, the operator would not know what device the user may use every time they try to
`access the network. In other cases, such as in service organizations, government agencies,
`or police department, users that belong to a team can share their devices with each other.
`
`Such refinements require more precise definition of the network usage and security policies
`that in turn means the architecture must be designed more carefully. The network operator
`may need to make sure that both device and user are authentic, possibly using separate proc-
`esses. In some cases, the device may have to even be manufactured and configured with
`credentials for access to the network. (For instance, cable modems for cable Internet Service
`Provider (ISP) networks are produced this way.) In such cases, proper protection must be in
`place, so that the credentials on the device can not be tampered with. The network operator
`also needs to make sure the user presents accurate identity and proper credentials that can
`identify her at the time of use, so that the various users can be distinguished even when they
`are using a shared device.
`Device authentication credentials can be certificates or cryptographic keys that are loaded
`in the devices either by the manufacturer in the factory or by the network operator at the time
`of service initiation. When designed properly and in a modular manner, the device authenti-
`cation process should be transparent to the user. In fact, the user should not even be allowed
`to access device authentication credentials. On the other hand, user authentication credentials
`are personalized, typically given to the user in an out-of-band method. Examples are over a
`phone call by the user stating some secrets about her identity or through a face-to-face
`meeting after presentation of a driving license, company badge, and so on. Upon identifica-
`tion of the user, the system operator issues the authentication credentials for the user. The
`credentials must be carried by the user at all times either memorized (password) or in the
`form of a token such as a secure ID card, a certificate on some sort of cryptographic module.
`The user applies her authentication credentials on the device provided for access to the
`network to connect to the network.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 3 of 23
`
`

`

`4
`
`AAA and Network Security for Mobile Access
`
`It should be noted that the security architecture may require both device authentication
`as well as user authentication in various steps of a network access process. An example
`would be the case of IP networks: in order to communicate to the IP network, the device
`needs to acquire an IP address. The IP address is not only an important resource for the
`network, but also allows the user to gain access to many other network services. Further-
`more, the IP address can be used as a backdoor to launch active or passive attacks. Hence,
`IP address acquisition should be tightly controlled. From a security standpoint, it means a
`device needs to first authenticate itself to the network before being able to gain an IP
`address from the network. Once the device is authenticated, has gained IP address from the
`network, and is registered with various agents, it allows the user to present her credentials
`to the network and gain access to the services to which she is entitled. The latter brings
`another point and that is the user credentials may be used to determine authorization levels
`for the users based on their pre-configured service profile. We will discuss the topic of
`authorization later on.
`
`1.1.2 Message Authentication
`Device or user authentications deal with ensuring that the end points of the communications
`are legitimate and who they claim they are. Message authentication, on the other hand,
`ensures and verifies the integrity of the data at hand (remember the example of sealed letter
`from the emperor). When message authentication is performed, the receiver of the message
`can be sure that the information included in the message has been produced by a legitimate
`source and not been altered by other parties in transit. This is why message authentication is
`usually considered as a data integrity protection mechanism. Unlike device or user authenti-
`cations that are typically performed at the beginning of a session and require their own
`messaging mechanism, message authentication may have to be done quite often during the
`session and for a variety of traffic, such as control messaging, important data packets, and
`sometimes even data session.
`Note that the goal of data integrity protection is to prevent malicious and intended corrup-
`tion of data by the so-called men in the middle (MITM), trying to tamper with the message
`contents. This is different from the information-theoretical codes and cyclic redundancy
`checks designed to mitigate the random and natural data corruptions caused by physical
`communications media imperfections. Aside from the cause of corruption being different,
`calculations required for message authentication for security protection is also different from
`its signal processing counter parts; an attacker can always alter the data and re-calculate the
`information-theoretical checks to lure the receiver, while the attacker cannot re-calculate the
`message authentication data added to the message, since message authentication is typically
`performed on the basis of knowledge of a shared secret.
`More details are provided on message authentication in Chapter 2, so we will not go into
`any details in this introductory chapter. In short, this is how message authentication works:
`the sender provides proof for data integrity by running a so-called secret hash algorithm
`over the contents of the message and adds the results of the algorithm (called digest or hash)
`to the end of the message. Hash algorithms are mathematical one-way functions. In other
`words, while it may be straightforward to calculate the output of a hash function (digest)
`from an input data packet, it is extremely hard to determine what input packet has been used
`to create the output digest. However, hash algorithms are rather well known, and hence if no
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 4 of 23
`
`

`

`The 3 “A”s: Authentication, Authorization, Accounting
`
`5
`
`secrets are used, it is possible for an attacker to change the packet in flight and re-calculate a
`new digest and then to replace both the original packet and digest with the altered packet
`and the new digest. In order to prevent the MITM from running the same algorithm over an
`altered version of the message, the sender uses a secret when creating the hash. The secret is
`only known to the sender and the receiver. This process is often referred to as running a
`secret hash algorithm, even though the algorithm itself is usually known. Once the receiver
`receives the message, it runs the same hash algorithm over the same portion of the data and
`compares the result of its calculation with the hash provided by the sender and if there is
`a match, the receiver considers the data authentic, otherwise the receiver needs to discard
`the data.
`The secret hash algorithms are examples of symmetric key authentication methods.
`Another method of providing message authentication is to create the so-called digital signa-
`tures. Digital signatures are typically based on public key cryptography. We will go through
`the details of these procedures in Chapters 2 and 3.
`
`1.1.3 Mutual Authentication
`
`We finalize the description of various authentication concepts with a short note on mutual
`authentication. Client authentication that was explained earlier is a unilateral authentication,
`where only one end of a communications channel proves that the identity it has presented to
`the other end is authentic. It would make sense that when establishing communications both
`ends authenticate to each other. However, the reason this type of unilateral authentication is so
`widespread is that in many cases, the client simply trusted the network. So the network does
`not have to prove to the client that it is also authentic. In the earlier cellular phone example,
`due to the large expense involved with setting up a cellular network, it would be hard to
`imagine that attackers will go through the trouble of setting up a whole network and its high
`towers simply to hijack a cellular phone subscription. For those reasons until very recently,
`neither the device nor the user required any authentication from the network.
`With a proliferation of large number of access providers competing for customers, a user
`may be confronted with a number of competing networks with which she does not have any
`business or trust relationships. Take a mom and pop coffee shop for example: a customer
`entering the coffee shop does not know whether the mom and pop that own a coffee shop
`actually know how to operate a wireless local access network (WLAN) access point (AP) or
`how to protect their access points from being loaded with viruses and Trojan horses. For all a
`user knows, another customer may have found the WLAN AP behind the coffee grinder
`machine, disconnected it and simply installed another AP to re-route all the traffic in the shop
`to some place else, or simply passively copy traffic to a server. Imagine, if the customer was
`planning to do some Internet shopping while sipping coffee and was entering her credit card
`number at an e-commerce web site not using proper encryption methods. In this case, it
`makes sense for the coffee shop AP to authenticate itself to the user’s device as well. As we
`can see the unilateral client authentication is not sufficient and has to be upgraded to a mutual
`authentication where the server also authenticates to the client.
`The mutual authentication between the client and the server is a special case of a more
`generic case of mutual authentication, where the two parties are simply peers as opposed to
`client and server. In that case, each peer authenticates to the other, either sequentially, or in
`parallel.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 5 of 23
`
`

`

`6
`
`AAA and Network Security for Mobile Access
`
`1.1.4 Models for Authentication Messaging
`
`1.1.4.1 Two-Party Authentication Model
`
`This model is used when the two peers interact with each other through a direct line of
`communication without the involvement of any middle nodes such as gateways or proxies.
`In such cases, the two entities directly authenticate to each other. The most prominent
`example is a direct client–server interaction, during which the client has to authenticate
`unilaterally to the server to gain access to service. However, mutual authentication can also
`be performed in direct two-party manner. As we will see later on, many key exchange
`mechanisms, such as Internet Key Exchange (IKE), require a direct two-party authenti-
`cation exchange.
`
`1.1.4.2 Three-Party Authentication Model
`
`With the increase in size of networks and number of users wishing to access the network and
`its services, the networks have started to deploy specific points of presence (POP), which are
`low-cost unsophisticated devices without large processing power or database capabilities.
`The POPs typically interact directly with the users, but refer to central internal servers for
`many tasks and decisions regarding interactions with users. One such task is authentication.
`The POPs are typically incapable of authentication processing. Therefore, the two-party
`authentication model has been expanded to include three parties:
`
`1. The supplicant, the user trying to gain access. In case of dialup networks, the user is
`configured with a phone number for the ISP modem pool and is given a password. The
`user dials the number of the modem pool and reaches one of the modems.
`2. Authenticator, at edge interacting with user. In case of dialup, the authenticator is at the
`modem pool. The authenticator has no authority by itself, and is like the security guard at
`the door of a corporate building. When a visitor, who has no badge, walks in, the guard
`needs to call the authorities to ask whether it should let the visitor in or not. As we will see
`later on, in the AAA model, this entity is called the network access server (NAS), which
`acts as a AAA client.
`3. Authentication server, who has the real authority and the necessary information database
`(e.g. a list of who is authorized, user names, and passwords) to make decisions regarding
`granting access to the user. In the security guard analogy, this is the boss upstairs that the
`guard calls to and the one who makes the ultimate decision. The AAA server in the AAA
`model is shown in Figure 1.1.
`
`Access link
`protocol
`
`User/supplicant/
`end client
`
`AAA protocol
`
`AAA client/
`NAS
`
`AAA server
`
`Service provider network
`
`Figure 1.1 The three-party authentication model deploying an AAA infrastructure
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 6 of 23
`
`

`

`The 3 “A”s: Authentication, Authorization, Accounting
`
`7
`
`1.1.5 AAA Protocols for Authentication Messaging
`In small networks, an authentication server could be configured by the system administrator
`at the authenticator, so the authenticator and authentication server are co-located. However,
`as we mentioned earlier, in large networks or multi-domain networks, this is not practical,
`and many network points of presence, acting as NASs are deployed and the authentication
`must happen according to the three-party model. Naturally, the end-to-end authentication
`exchange needs to happen between the supplicant and the AAA server, but the NAS is also
`involved in the exchange of authentication-related messaging. Since the NAS controls
`communications into and out of the private network, it needs to intercept messaging between
`the supplicant and AAA server. Furthermore, the NAS typically acts as a protocol dividing
`point, since the communications to the AAA server side of the NAS typically happens over a
`private and typically wired and trusted part of the network, while the communications on
`supplicant-side of the NAS is over an untrusted and many times wireless medium. In order to
`provide interoperability between various network equipments, protocols for various segments of
`the three-party model have been standardized. The protocols for communications between
`the NAS and the supplicant typically depend on the type of access technology that the
`network provider offers and many times are at a lower layer (link layer). However, the
`NAS communicates with the central authentication server over standard UDP/IP or TCP/IP
`protocols and can use a standard protocol for carrying authentication messages on behalf of
`the supplicant and the server. As we will see later on, experience has shown that the authenti-
`cation server can be co-located with entities performing authorizations and accounting as
`well (a AAA server). For that reason, the protocol between NAS and the authentication
`server is now a AAA protocol as follows.
`
`1.1.5.1 User–AAA Server
`
`As mentioned earlier, there is no direct communication between user and AAA server. The
`most prominent AAA protocol today, RADIUS (stands for remote access dial in user
`service), was designed to allow a NAS forward a user’s request and its credentials to
`the server, and then carry the server’s response back to the user. The Access-Request,
`Access-Challenge message structure in RADIUS shows that it was designed to accommodate
`password-based authentication methods, so that NAS can forward an authentication request
`message from the user to the authentication server and issue eventual challenges created by
`the network and present to the user.
`
`1.1.5.2 NAS–AAA Server Communications
`
`As mentioned earlier, this communication is typically on a private part of network. A AAA
`protocol, such as RADIUS protocol, is used for this purpose. Original assumption was that
`there is only one hop between the NAS and the AAA server. However, multiple hops
`deploying AAA proxies may be required. We will discuss AAA proxies in Chapters 6
`and 7. It is important to note that when proxies are involved, the NAS–AAA server
`communication may no longer be over a private network. This means the information
`carried between the NAS and AAA server over the AAA protocol may need special
`security protection.
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 7 of 23
`
`

`

`8
`
`AAA and Network Security for Mobile Access
`
`1.1.5.3 Supplicant (User)–NAS Communications
`
`This communication is typically over a single-hop link called access link, since it is part of an
`access network. The access link provides a physical channel and a link layer protocol. The
`physical channel only provides the coding and modulation of information bits into electrical
`signals. Neither the earlier phone line dialup connections nor the later cellular systems
`provided layer-2 services, such as packet formatting, framing, and multiple-access mechanisms,
`and required specific layer-2 protocols such as point-to-point protocol (described in Chapter 2) for
`this purpose. The new wireless access technologies such as 802.11 WLAN have their own
`framing mechanisms and do not need additional protocols such as PPP for carrying layer-2 level
`messaging. However, the main point is that as we mentioned before, the IP-level service should be
`established after the initial authentication and hence, the user–NAS exchange of authentication
`messages need to run directly over an access technology-specific layer-2 protocol.
`
`1.2 Authorization
`Authorization is defined as the act of determining whether a particular privilege can be
`granted to the presenter of a particular credential. The privilege can be right of access to a
`resource, such as a communications link, an information database, a computing machine, or
`many other things owned by a network or service provider. The presenter of the credential
`can be either a device or a user.
`
`1.2.1 How is it Different from Authentication?
`
`The problem of authorization and its distinctions from the problem of authentication can be
`easily explained with the following example. Let us assume that a person, holding a
`personal handheld device such as a wireless-link enabled PDA, has subscribed with a high-
`priced network operator. This person requests to see some movie clips on his personal
`device. She uses her personal device to connect to a wireless network, and based on the
`credentials that the network provider has given to her at the time of subscription, she can
`authenticate through her PDA and connect to the network. In many of the networks today,
`this authentication would be enough for her to access the movie clips from a server located
`inside the operator’s network. However, imagine if the network provider would charge
`different prices for different movies or download speeds. A lower paying user is allowed to
`download the clips at a much slower speed. The user may request a higher quality of
`service (QoS) by agreeing to pay a one-time premium. In this case, a mere verification of
`user identity would not be enough for granting the service requested by the user. The
`network must somehow access the user profile, consult entities controlling the amount of
`available bandwidth, and then make a decision on whether or not to authorize the user to
`access the service.
`Another commercial example where authorization is important is networks that provide
`service to users that have purchased pre-paid cards. A cellular phone user buys a pre-paid
`card that is supposed to allow her to make phone calls for three hours. Every time such user
`requests to make a phone call, the network must check to see whether there is any credit left
`on the user’s card before allowing the user to connect.
`In commercial applications, the problem of authorization usually either translates to
`protection of revenue or to exercising the right to a service. However, in public safety,
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 8 of 23
`
`

`

`The 3 “A”s: Authentication, Authorization, Accounting
`
`9
`
`military, and security applications, the consequences may be more severe. A low ranking
`officer should not be authorized to join a conference call held between army generals. Public
`safety responders may have special units dealing with specific emergencies, such as high-rise
`building fires. Dispatch calls or conversations within the unit need to remain private within
`the group, both for privacy issues and to save bandwidth. A fire fighter who is not part of a
`special unit should not be allowed to join the channel reserved for that special unit. In such
`a case, once the fire fighter and his device is authenticated to the network, the network must
`pursue with the act of authorization, i.e. check his profile against what is required to
`authorize an agent to join specific calls on specific channels.
`Historically, a private enterprise owning the computer or radio networks simply authorized
`its employees or affiliates for use of its resource as long as they could prove their affiliation
`to the enterprise. The credentials for proof of affiliation were the authentication credentials
`that were given to the user at the time of initiation with the enterprise (as described in section
`1.1 before). Once the user was authenticated, she was also authorized for service, in other
`words not only the authorization was equated with authentication, but also the credentials
`presented for authentication were also used for authorization. This model still exists in many
`enterprise networks: the second A (authorization) is coupled with the first A (authentication)
`in AAA. In commercial networks, authorization is based on acquisition of revenue, i.e. if the
`network provider knows it can collect payment from the user of the service, the user will be
`authorized for service. Here the second A is coupled with the third A (accounting). The user
`subscribes for a service and agrees to pay a fee for the service and the network provider
`agrees to provide the user with the service. However, even though we said that authorization
`is coupled with accounting and billing, this is only in theory (business agreement paper
`work). In practice, the network operator implements this agreement by giving the user the
`authentication credentials and again bases authorization on authentication.
`Now that we have established that there is a difference between authentication and author-
`ization, let us discuss another extreme example from real life, where authorization is actually
`more important than authentication. When we want to go see a movie at a movie theatre, we
`will pay the cashier and buy a ticket. Let us assume we pay cash and we are adults that are
`not bound by the viewing rating; once we receive the ticket, that ticket alone is all that we
`need to go to a hall and see the movie. The ticket is the credential needed to authorize us to
`see the movie and hence is a perfect example of authorization credentials. The movie ticket
`cannot be used instead of a passport to get onto an international flight. In other words, it is
`completely worthless as authentication credential (to verify our identity).
`The networking counterpart of the movie ticket is the pre-paid calling card that is
`becoming popular. The pre-paid card allows the card holder to make a phone call through
`a network provider’s infrastructure and the provider does not care who the user is as long as
`there is still credit left on the card.
`
`1.2.2 Administration Domain and Relationships with the User
`
`At this point, it is useful to also describe the concept of administrative domain: According to
`RFC 1136 [ADMRT1136], an administrative domain is “a collection of end systems, inter-
`mediate systems and sub-networks operated by a single organization or administrative
`authority”. In AAA language, this typically means that the domain is served by the same
`AAA server (or pool of synchronized AAA servers, if failure recovery is important) and is
`
`Apple v. Maxell
`IPR2020-00202
`Maxell Ex. 2028
`
`Page 9 of 23
`
`

`

`10
`
`AAA and Network Security for Mobile Access
`
`ruled by the same network policies. When a user affiliates with a private network or
`subscribes with a commercial network provider, it is said to belong to the administrative
`domain. The AAA server within the domain is said to act as the user’s home AAA server
`(AAAH or HAAA). The user’s information and credentials are then stored at that AAA
`server and the user is said to have a trust relationship (and business relationship for commercial
`networks) with the administrative domain and its AAA server.
`In a more general case, a user may roam to a network that is not part of its home adminis-
`trative domain. The user may request services from this visited domain, which does not have
`any trust relationship with the user. In this general case, the service equipment, providing the
`service to the user, is part of a different administrative domain than the user’s home domain
`and the visited