Chapter 3 System architecture
3.4 System scenarios
This section discusses the scenarios and authentication procedures of the proposed method.
3.4.1 Domain relation and certificate chain
With the environmental assumption in the chapter 3.1, there would have a MO in an area. The MO cooperates with the other operators in the area to extend the coverage of service region. Because the MO is a trusted third party for the other operators, the MO of an area can act as the root CA to issue certificates to the ASs of the operators which have roaming agreement with MO. Then AS issues certificates to APs of its service domain. Hence, starting from the root CA, a certificate chain is established among MO, AS and AP of the same communication network.
Two certificates issued by the same root CA imply a trust relation by verify the certificates of each. Only when the MO and the domain have roaming agreement or trust relation, the root CA issues a certificate to the domain. By trusting the MO as a root CA, when domain A successfully verifies a certificate of domain B which issued by the same root CA, domain A can trust domain B as valid. Then a trust relation is established between the two domains. Accordingly to the concept of certificate chains, the trust relations can be dynamically established between different domains.
Figure 3.2 Domain relation and certificate chain
MOs in different areas may have roaming agreement to allow user mobility between the two communication domains. When MOs have roaming agreement, they issue the certificates to each other to connect the two certificate chains of each network domain. As shown in Figure 3.3, MO1 has the certificates issued by MO1 and MO2, and MO2 has the certificates issued by MO2 and MO1. When ASB wants to verify ASC, it follows the chain to get 2<<C>> and 1<<2>>. MO1 is the trusted authority of ASB, so the verification started from ASB will stop at MO2 and come out a positive result. The detail process of verification is depicted as:
2P =1P1<<2>>, CP =2P2<<C>>, verify successfully.
Figure 3.3 Establish trust relation across different MOs
3.4.2 Register in home domain
Before MN accessing a wireless networks, it should register to a domain and get a certificate from AS. MN may also cache the certificates of domains which have roaming agreement with its home domain.
3.4.3 Visit a network
When MN is turned on and visits a domain, it should do authentication with its home domain to confirm validity. If MN visits a non-home domain, the roaming agreement between visited domain and MN’s home domain needs to be checked. If there is no roaming agreement between them, two domains use the certificate chain verification to determine that the other domain can be trusted or not. After certificate chain verification succeeds, the trust relation and roaming agreement are established between the domains. We particularly discuss the visiting situations and the corresponding processes of them below.
A. If MN visits its home domain
1. MN do full authentication with AS via AP.
2. After authentication succeeds, AP caches context information including PMK, and certificate of AS. MN caches context information including PMK, and certificate of root CAHome.
B. MN visits a domain which has roaming agreement with MN’s home domain 1. MN do full authentication with home AS via AP.
2. After authentication succeeds, AP caches context information including PMK, and certificate of MN’s home AS. MN caches context information including PMK, and certificate of root CAVisit.
C. MN visits a domain which has no roaming agreement with MN’s home domain 1. If the visited domain and home domain trust the same root CA or they trusted
CAs trust each other such as the ASA and ASC in Figure 3.3. Two domains do certificate verification firstly to establish the trust relation between each other.
2. MN do full authentication with home AS via AP.
3. After authentication succeeds, AP caches context information including PMK, and certificate of MN’s home AS. MN caches context information including PMK, and certificate of root CAVisit.
3.4.4 Handover processes
When MN moves to the range of new AP and wants to re-associate with the new AP, it sends a re-associate request message to new AP. The following discusses the situations of roaming and corresponding processes.
A. Roam to the same domain as current AP. Or roam to a new domain that has cooperation with current domain.
(1) MN sends a re-associate request to the new AP includes the MAC address of current AP, and the ESSID and MAC address of MN.
(2) New AP sends MAC address of current AP to AS to get the IP address of current AP. If the secure connection has not been established, transfer the Security Block messages firstly.
(3) New AP sends MAC address of MN to current AP in order to verify that the association of MN in current AP is valid or not.
(4) Current AP transfers MN’s relevant context including PMK, and certificate of MN’s home AS to new AP.
(5) New AP sends re-associate response to MN.
B. Roam to a new domain which does not have cooperation with current domain.
If the new domain and current domain both have cooperation with the same MO and have certificates issued by the same root CA, or they in different MO but their cooperating MOs have roaming agreement, the new domain and current domain do certificates verification to establish trust relation. After the above-mentioned processes, do the processes as situation A which discussed before does.
However, if the new domain can not establish a trust relation with current domain but has a roaming agreement with MN’s home domain, MN does a full authentication with its home domain via new domain.
After re-association succeeds, current AP becomes old AP and new AP becomes current AP.
Figure 3.4 Handover processes
3.4.5 One-hop re-authentication
When the keys become overdue or AP or MN wants to recheck the validity of the other side, the re-authentication is needed. But the new visiting domain may not have roaming agreement with MN’s home domain in inter-domain roaming. MN can not do authentication with its home domain directly. It would be a serial secure problem in roaming. Therefore we propose a one-hop re-authentication to let MN and AP can verify each other without relying on AS.
MN and AP use certificates to do EAP-TLS full authentication. MN has certificate issued by its home AS. AP has certificate issued by AS. When MN visited the old domain, it got the certificate of CAVisit which is the root CA of visited domain.
therefore MN check the next certificate. The certificate of current AS is signed by CAVisit which is trusted by MN. Therefore, MN uses the public key of CAVisit to verify the signature in the certificate of current AS which is signed by the private key of CAVisit. And then MN uses the public key of current AS to verify the signature in the certificate of current AP. After verification succeeds, MN can be sure the AP is valid and is trusted by the CAVisit. In the other hand, AP verifies the certificate of MN by the certificate of MN’s home AS which is transferred from old AP via IAPP in the same way as above-mentioned.
Figure 3.5 One-hop re-authentication