We will now present a variant of the connection setup protocol where the home network HN does not take part in the connection establishment phase. In this section, the MD is connected to the FN over a direct wireless link. Connections over another Hop are discussed in the next section.
3.6.1 Scenario and Requirements
In the HN offline solution, the HN will only be contacted during the clearing phase. This reduces the overhead of communication between operators, and the connection to the HN does not have to be established for every individual connection but only in regular intervals, e.g., daily. A high latency in the network connection between the FN and the HN will not delay the offline connection setup protocol, which is especially interesting when the FN and the HN are geographically distant. The scenario is also interesting when HN does not have a high-bandwidth connection itself, e.g., for HNs that do not operate any access points themselves. A similar concept is established in cellular phone networks, where these operators are known as Virtual Network Operators (VNOs): VNOs pay for use of the network infrastructure instead of owning it.
Figure 3.10 provides a high level overview on the protocol suite and the entities involved in the different protocol phases. Like the HN online roaming protocol suite, the offline roaming protocol suite consists of a connection setup protocol, a tick payment protocol, and two different clearing protocols. Also like the HN online protocols, the connection setup protocol can be implemented as a new key-generating EAP-method for use in WLAN. The key established during the protocol could then be used as pair-wise master key in the IEEE 802.11i 4-way handshake to establish a confidential and integrity protected connection between the MD and the AP of the FN.
3.6. Roaming with HN Offline Directly 73 Visitor MD Visited Operator FN Home Operator HN Tariff Announcement Tariff Recommenda-
tion and Selection
Connection Setup Phase: Tariff Selection, Key Setup, Init Payment and Service Usage Phase
Clearing Phase (participation optional)
Billing (Offline)
Figure 3.10: Phases of the Direct Roaming Protocol Suite with HN Offline During Setup
The offline connection setup protocol also includes secure tariff negotiation between the MD and the FN as well as the secure initialization of the tick payment. The tick payment protocol is also set up similar to the online case.
The offline roaming protocol suite aims to meet the following goals:
Sec-1: Mutually authenticated key establishment between the MD and the FN Sec-2: The MD can avoid an FN that acted dissatisfactory in the past.
Sec-3: Outsiders cannot read or modify the MD’s traffic (Confidentiality, In-
tegrity).
Sec-4: Perfect Forward Secrecy
Sec-5: Key Confirmation between the parties
Pri-1: The MD must stay anonymous to anybody (Anonymity).
Pri-2: The MD must stay untrackable to anybody (Unlinkability).
Pri-3: No one can learn details about MD’s session with the FN, e.g., the HN (Information Privacy).
Pay-1: The MD will never have to pay for services it did not use.
Pay-2: The FN will be paid by the MD for the services the MD uses (Non-
Repudiation).
Pay-3: The FN cannot charge more than negotiated with the MD (Non-
Repudiation).
In the following, we will first describe some foundations of certificates used in the HN offline solution. Then, the protocol will be presented and discussed in detail. An extension of the HN offline connection setup protocol (described here) to allow con- nections over a Hop is presented in Section 3.7. Details on the payment mechanism during service use and clearing are discussed in Section 3.9.
74 Chapter 3. Roaming in Wireless Networks
Cross Certification and CRLs
As a new requirement over the HN online scenario, the operators that want to enable roaming among their users issue cross-certificates to each other. For the operators A and B to cooperate, certA(B) and certB(A) are created. Operator A is distributing
certB(A) to its APs. These certificates are then transmitted via one-way broadcast
by the APs such that the MD can obtain them before transmitting any signals, and before authenticating to a WLAN. E.g., the APs of Operator A are broadcasting
certB(A), which all MDs of Operator B will be able to verify using the public key
PK(B) of Operator B that they store.
The are two kinds of certificate revocation lists (CRLs): CRLs of revoked FNs, and CRLs of revoked MDs. Both are shared between the operators. The CRLs of revoked MDs are only shared between the operators and not published in any way. Each operator is broadcasting in its network the current CRLs of revoked FNs, which are generated by all the operators that have cross certified this operator. These CRLs can be obtained by any MD within the range of FN’s access points. Each MD is able to verify the CRLs using the public key of its home network PK(HN) it already knows. MDs must use services with a network whose operator presents an invalid certificate or no current CRL of the HN. All CRLs are signed by the issuing party and have timestamps for their creation and expiration times.
Pseudonym Certificates
The MDs carry a list of pseudonym certificates (called PCs in the following) and the corresponding signature creation keys. The PCs are used by the MD to achieve anonymity against the FNs, i.e., they do not contain the user’s real name, so that the FN cannot learn the true identity of the MD. When the MD uses a different PC each time it visits an AP run by the same FN, the FN is also unable to track the MD. These certificates and keys are issued by the HN and can be used in any order by the MD to authenticate to FNs.
The HN is able to revoke PCs when the corresponding MDs are stolen, overspending, or fail to pay after the clearing phase was executed. The FN keeps track of the PCs revoked by the HN with the help of the CRLs discussed above and will refuse new connections with an MD using a revoked PC.
3.6.2 Offline Connection Setup Protocol
Like the online connection setup protocol, the offline connection setup protocol is ex- ecuted over a publicly visible, unencrypted, and unauthenticated channel. It includes discovery of tariffs, certificates, and CRLs; authentication and key establishment, tariff selection, payment initialization, and the first tick payment. Immediately after the offline connection setup protocol is executed, the MD can access the Internet via FN’s access point.
3.6. Roaming with HN Offline Directly 75 MD FN 1. tariffs, certHN(FN), CRLs verify CRL, certHN(FN) 2. tM D 3. tF N,sigF N(tF N) verify 3 4. EK(b,PC),sigP C tM D, tF N, h(b), ID(FN), PC verify PC, 4 5. EK(h(b,PC)),sigF N tM D, tF N,ID(FN), PC, h(b) verify 5 802.11X four-way handshake, MSK derived from tM DrF Nmod p, payment chain α
Figure 3.11: HN Offline Connection Setup Protocol, Signatures denoted red
The offline connection setup protocol is illustrated in Figure 3.11 and the message exchange is described in detail in the following. Throughout the protocol description the notations summarized in Table 3.5 are used.
1. The MD downloads the service advertising broadcast message from all the APs within its radio reception range. These broadcasts from the FNs each contain cross certificates, CRLs, and offered tariffs. When cross certificates are present in the broadcast, the MD executes the offline setup protocol.
The MD selects an FN AP that offers a suitable tariff (decided by user pref- erence), which has sent a recent CRL signed by its HN and an unexpired and unrevoked cross certificate certHN(FN) which was created by the HN of the
MD. If the verification of the CRL and cross certificate succeeds, the MD es- tablishes a connection to the FN. The MD selects one of the tariffs offered by the FN to use for this connection, possibly with the help of a tariff recommen- dation system.
2. The MD chooses the private DH value rM D ∈R Zp and calculates the public
DH value tM D = grM Dmod p, which is sent to the FN in message 2.
3. The FN chooses the private DH value rF N ∈R Zp and calculates the public DH value tF N = grF Nmod p. The public DH value tF N is signed by the FN
and sent to the MD.
4. The MD verifies the signature by the FN from message 3 with PK(FN) from the FN’s cross certificate. The MD selects a pseudonym certificate PC to use for this connection.
The MD generates a payment chain in a similar way as in the HN online direct connection solution: MD chooses random values IV and α0 to calculate
76 Chapter 3. Roaming in Wireless Networks
the maximum amount of hashes as indicated by the selected tariff. No value may appear twice in the payment chain α, because it would create a loop. If there is a loop, new values for IV and/or α0 must be chosen. The first tick payment is αT −d = HT −d(α
0). The payment information is summarized in
b = (IV, αT, αT −d, selected tariff).
The MD calculates K as a derivation of tF NrM Dmod p, and uses K to encrypt
PC and the payment information b for the FN. The MD signs all public DH values, a hash of b, the ID(FN), and its PC. The data is sent to the FN. 5. The FN calculates K as a derivation of tM DrF Nmod p, and uses K to decrypt
the PC and the payment information b from the MD. The PC must be a certificate that is signed by a CA that the CA of the FN has issued a cross certificate for. The PC must not be revoked. The public key from the PC is used to verify the signature by the MD. The received ID(FN) must match its own ID. Hd(αT −d) must match αT, and the values must be new.
When all verification steps were successful, the FN generates message 5: The FN encrypts a hash of the PC and the payment information b for the MD to facilitate key confirmation. The FN creates a signature on the public val- ues tM D, tF N, its ID, MD’s PC, and a hash of the payment information b to
authenticate MD’s public value and the identifiers.
The MD will then verify the signature by the FN for authentication and the value inside the encrypted block for key confirmation.
At the end of the protocol run, a derivation of tM DrF Nmod p is used as the MSK
for an 802.11X four-way handshake. When the MD and the FN have completed the four-way handshake, the FN provides the first service interval to the MD at the tariff selected by the MD. Further service intervals and clearing are discussed later in Section 3.8 on the payment protocols.
3.6.3 Discussion of the Offline Connection Setup Protocol
The offline connection setup protocol illustrated in Figure 3.11 offers the following security and privacy features:
Sec-1: Mutual authentication is achieved as both parties include the ephemeral
public keys from messages 2 and 3 within the signed parts of messages 3, 4, and 5. Therefore, both parties are aware that the other party is actively participating in the current protocol run. The MD is able to verify FN’s signature based on the cross certificate certHN(FN) received in the first protocol message. The FN is able to
verify MD’s signature after decrypting message 4, which contains the MD’s chosen pseudonym certificate PC.
The key established during each protocol run is fresh as the ephemeral DH param- eters are chosen by both parties for only this session. Explicit key confirmation is achieved by the encryption of messages 3 and 4 with the fresh key K. Signatures in message 3 and 4 provide entity authentication. Thus, mutual belief in the key K is achieved.
3.6. Roaming with HN Offline Directly 77
The use of K to encrypt b and PC in message 4 provides key confirmation from the MD to the FN, as both b and PC have a well-known structure. The encryption of h(b,PC) by the FN proves to the MD that the FN is in possession of the key
K, as the FN was able to decrypt in message 4 and able to encrypt in message 5.
Because the values K and b are fresh in every new connection, an attacker cannot use a replay of an old EK(h(b,PC)).
The FN proves trustworthiness to a client of the HN by presenting the cross cer- tificate signed by the HN in the service advertising broadcast message 1. The FN proves identity to an MD by signing the public parameter sent by the MD with a signature key corresponding to the verification key presented in the cross certificate sent in message 1. The MD proves trustworthiness by presenting a certificate signed by its HN.
Note that timely certificate revocation between the operators is required, but out of the scope of this document.
Sec-2: The FN presents a cross certificate signed by the HN to the MD. The HD
will not issue certification on multiple identities for a single FN. The certificate is issued on the signature key which is used during the connection setup, so that the certificate of an FN cannot be used by an attacker. Thus, the FN must present its own certificate, so that the MD can avoid an FN that has acted dissatisfactory in the past.
Sec-3: At the end of the protocol run, a derivation of the established key tF MrM F is
used as MSK in the 802.11X four-way handshake. The following connection is CCMP protected, and thus outsiders cannot read or modify the MD’s traffic (Confidentiality, Integrity).
Sec-4: Perfect Forward Secrecy is achieved as the long-term keys (signature
keys by MD and FN) are not used to calculate the session keys. All the session keys are created using a Diffie-Hellman key agreement mechanism, which provides perfect forward secrecy.
Sec-5: Key Confirmation of K is achieved as described in the following: The MD
encrypts b,PC for the FN. The FN decrypts, hashes, and encrypts this data for the MD. This proves to the MD that the FN is able to decrypt and encrypt. As b and a hash of the PC is contained in the signatures by the MD and the FN, the contents of the encryption can be compared to the contents of the signature. This provides
key confirmation for both parties.
Pri-1: The PC is a certificate issued on a pseudonym ID generated by the HN for
the MD (or generated by the MD and signed by the HN). The pseudonym hides MD’s identity, thus achieving anonymity.
Pri-2: While the use of a single pseudonym creates anonymity, the use of many
pseudonyms also creates unlinkability. Therefore, the MD carries an array of PCs and the MD can choose which of his PCs to use in each new session. In order to stay unlinkable to an FN, the MD has to use a different pseudonym certificate on every connection setup with the same FN. Using the same pseudonym with different, non-colluding FNs does not lead to linkability when the FNs do not collude.
78 Chapter 3. Roaming in Wireless Networks
Pseudonym certificates are never sent in the clear. Even when encrypted with a fresh key, the pseudonym certificate will only be sent after the FN has authenticated to the MD.
As a fresh payment init value b is required for each protocol run, the use of a proper block mode for the encryption of EK(b,PC) ensures that no individual block of the
ciphertext remains constant, even when the same PC is used twice. E.g., ECB mode with padding b to exactly one cipher block length would lead to a constant encrypted PC. Therefore, CBC or counter mode should be used. With this strat- egy, less pseudonym certificates can be used while retaining unlinkability. To stay unlinkable, the MD also has to change its MAC address between two connection setups. Otherwise, even passive eavesdroppers are able to recognize an individual MD.
Pri-3: HN is not contacted during the setup phase, and b is only transmitted in
encrypted form, thus hiding it from anyone but the MD and the FN. Therefore, no one can learn details about MD’s session with the FN (Information Privacy). The practical goal of tariff negotiation is achieved in a similar way as in the direct connection protocol as discussed in Section 3.4.3.
The goals for payment, Pay-1, Pay-2, and Pay-3 are discussed in Section 3.8 discussing the payment and clearing protocols.