Extra Reading Materials

A Security Framework in RFID Multi-domain System

Posted on December 3, 2009 by admin

Original Paper Written by
Dong Seong Kim, Taek-Hyun Shin, and Jong Sou Park
Network Security and System Design Lab., Hankuk Aviation University, Seoul, Korea
{dskim, eureka57, jspark}@hau.ac.kr

Suppose that there are two different RFID domains under collaboration. Their security policies are different each other and don’t share any common information. There is a RFID tag x belongs to RFID single domain A (see Figure 1). The forehand security mechanisms between tag X and the reader can be applied according to the specification of tag X. The authentication protocols enable RFID reader to determine whether the tag X is legitimate or not. Moreover, RFID reader authentication can be performed.

Figure 1: A RFID multi-domain system

Once tag X is identified, the information of tag X and its related information can be stored in IS server in format of PML through RFID middleware. RFID middleware filters the malicious data from illegitimate RFID tag. The ONS is used to retrieve the information of tag X. ONSSEC also can be used to make the transaction between IS server and ONS server secure. And existing security protocols such as SSL can be used to provide secure transaction between backend system entities.

The tag X is attached on an object (e.g. an item, a case, and a pallet) and moved to domain B. In this paper, we assume that only actual users who have network connection to a domain can access other domains. (We will investigate the case in which RFID tag itself is used as representation of user in future work, for example, a passport which contains a RFID tag can be used to authenticate a user). Suppose that there are user p and user q who belong to domain A and B, respectively. The user q requires authenticating her identification to domain A if she wants to get permission to tag X, since tag X belongs to domain A. And the permission to be granted to user q will be determined on the security policy of domain A. This problem can be considered as the authentication and authorization problem in the RFID inter-domain.

Figure 2: The authentication and authorization in RFID single domain.

According to location of users’ service request, we classify the authentication and authorization into two cases: The one is the case that authentication and authorization for users is performed in a single RFID domain if users’ service request is stemmed from internal in the single RFID domain. The other is the case that authentication and authorization for users is performed in the RFID inter-domain if users’ service request is out of responding RFID domain. This paper proposes an authentication and authorization methodology in EPCglobal Network, since RFID system developers have been mainly implementing their system with respect to standards published by EPCglobal Network.

In EPCglobal standard describes that authentication and authorization will be processed in EPC Information Service (EPCIS) or EPC middleware. We assume authentication and authorization is performed in IS server. First, a flow of the authentication and authorization in single RFID domain is depicted in Figure 2. The user p presents a service administrator in EPCglobal Network belongs to domain A. IS server A represents Information Service server A in EPCglobal Network. The Reader and Tag represent RFID reader and Tag, respectively. The user p sends an authentication request to IS server. The IS server replies to user with authentication and authorization information of the user p. The access request is granted if the user q is authenticated by IS server; otherwise the access request is rejected. The user p may use service of reader and/or tag with respect to authorization granted by the IS server in domain A. The role of user and authorization information needs to be specified.

Figure 3: The authentication and authorization in RFID inter-domain.

Second, a flow of the authentication and authorization in RFID inter-domain is depicted in Figure 3. Suppose that domain A and domain B have the trusted security association beforehand. The user q is registered, authenticated, and authorized in domain B. In this situation, user q sends a service request with user’s authentication information (e.g. password, certificate, and so on) to domain A. The user q sends request for authentication to domain A, not domain B. This implies that authentication and authorization are delegated to domain A from domain B. This is one of the important parts in authentication and authorization in RFID inter-domain. After user q sends the request to the domain A, the domain A sends it to the domain B. The IS server in domain B responds to domain A, with the requested information, including identification and attributes of the requested user q. The IS server in the domain A determines whether it accepts or denies the requested user q. If the user q is authenticated and authorized, the user q is able to make use of services with respect to users’ authorization. The user q may use reader or tag in the domain A. The detailed flow of authentication and authorization for RFID inter- domain is depicted in Figure 4.

Figure 4: The detailed authentication and authorization in RFID inter-domain.

In Figure 4, there is the RFID domain A, B. The security assertion and delegation is performed between two domains. Each domain consisted of SA (Security Authority), PEP (Policy Enforcement Point), RAP (Resource Access Point), and PDP (Police Decision Point). The individual components represent the individual function in each domain.

SA manages the assignment of roles to users and the Role Assignment Policy. PEP executes accept/deny for user authentication and assignment/rejection for user authorization. PDP decides assignment/rejection for authorization and manages access control policy. RAPmanages access control of user to resource. Beside, role assignment policy defines policy for user’s role based on XACML. Resource access policy defines policy for user’s role from other domains, it is also based XACML.

The user q wants to use service or resource in domain A. As mentioned earlier in Figure 3, the user q sendsrequest to domain A, not domain B. This means that authentication and authorization procedure are carried out between domains not in end user side. The user q in domain B requests his/her authentication with X.509 PKC (Public Key Certificate). In this phase, X.509 PKC is used, but this may be replaced other mechanisms, including the simple ID/password authentication, challenge response protocol. PEP in domain A determines whether it accepts or deny user’s request with respect to the user’s authentication information. If the authentication information of user q is valid, PEP in domain A responds with query of user’s attribute to PEP in domain B. Otherwise, the user’s request is rejected and the session is terminated.

At this moment, the domain employs the Security Assertion Markup Language (SAML) [1], which is a standard to exchange attributes information between different domains. The subject in SAML message represents identity of user (e.g. A. Smith, M. Jordan) in SAML message format. SA in domain B receives attributes query from domain B and assigns user’s role and attributes according to policy in policy assignment point in domain A. The eXtensible Access Control Markup Language (XACML) [2] is employed to provide fine-grained access control. Then, SA in domain B sends response message in which contains the user’s role and attributes, to domain A. The PDP in domain A determines which role and attributes are given to the requested user according to domain A’s security policy, role assignment policy. For instance, assuming that a user q in domain B has a student role, domain A might give him/her a guest or a student role according to own security policy. The domain A sends authorization state and authorization message to its own RAP. If authorization is permitted to the user q, the user q may have several authorizations to resource in domain A.