REQUISITOS DE OCUPACIÓN DEL PUESTO

Given that our target service is to identify good communication requests, which is low-risk interactions, we analyze our security requirements as follows:

SEC-REQ-1: Data confidentiality. When transmitting user attributes and the infor- mation which is used to retrieve user attributes (e.g., an ARID access code) over networks, all entities must use a secure channel to prevent eavesdrop- ping and replay attacks. Protection the confidentiality of user attributes

and all related information is not necessary at trusted intermediaries such as SIP or SMTP servers.

SEC-REQ-2: Data integrity. Similar to data confidentiality, when transmitting user attributes and all related information over networks, all entities must use a secure channel, such as TLS, to prevent message tampering.

If a relying party is received user attributes not directly from the issuer, but via the principal, these user attributes needs to be signed by the issuer. This application-level signature requires verification by the application, some- times leading to complexity in parsing multipart message bodies in SIP and email. Our mechanism intends to avoid this complexity, by sending user attributes by reference so that a relying party can retrieve user attributes directly from the issuer.

SEC-REQ-3: Issuer authentication. When requesting and generating an attribute credential, the principal needs to authenticate the issuer with its X.509 PKC or pre-shared credentials. In addition, a relying party needs to authenticate the issuer by the issuer’s X.509 PKC or other mechanisms.

In our mechanism, the issuer authentication is performed with its X.509 PKC during the TLS handshake by the principal when it requests an ARID and by a relying party when it establishes the validity of the ARID.

SEC-REQ-4: Limiting relying parties To reduce the effect of replaying attacks (Sec- tion8.6.2), this mechanism needs to enable the principal to limiting relying parties who can retrieve the principal’s attributes. If the issuer validates an attribute credential (e.g., AVS), given no mutual trust relationship be- tween the issuer and a relying party, the issuer needs to authenticate a relying party as someone whom the principal has authorized. If a relying party validates an attribute credential without accessing the issuer (e.g., U- Prove), the relying party himself needs to detect replay attacks, namely, to determine whether an attribute credential is meant to himself or someone else.

For this purpose, in our mechanism, when receiving a validation request, the issuer of an ARID needs to authenticate a relying party with the access code associated with the ARID, provided by the principal. The access code is not the relying party’s CEID since the issuer cannot authenticate it. However, each relying party needs to generate the access code by computing the hash of his CEID and a secret sent from the principal, as described in Section 8.3.3.

SEC-REQ-5: Proof of possession of an attribute credential. To prevent replay attacks using received or stolen attribute credentials (Section 8.6.2), the principal needs to prove a relying party that she possesses an attribute credential (an ARID). Given no requirements of the principal’s CEID au- thentication below and the requirement of ease of deployment, this proof needs to be performed without authenticating her CEID.

This requirement contraint is relaxed by one of the requirements excluded because of the low risk of our target service. A described below, this does not have to prevent transfer or delegation of an attribute credential.

We exclude the following requirements since this mechanism is used for protecting a relatively low-risk interaction.

• No need for user accountability to the relying party, namely, no user au- thentication. A relying party needs to know user attributes as a hint to estimate the goodness of a communication request. Thus, a relying party does not need to trace uniquely to the principal, which is called the principal’s accountability [Kissel, 2011]. For this reason, authenticating an origin ID of a communication request is not needed [Kent and Millett, 2003].

• No need for non-repudiation of using an attribute credential. According to the term definition in [Kissel, 2011], “non-repudiation” is the security service that a sending entity cannot deny having sent a message (non-repudiation with proof of origin), and the receiving entity cannot deny having received a message (non-

repudiation with proof of delivery). For our target service, neither non-repudiation with proof of origin nor delivery is needed.

• No need to prevent transfer or delegation of an attribute credential. Due to the low risk of our target service, the mechanism does not need to support any special features to prevent the principal from giving her ARID to others. In addition, this mechanism does not support the principal who delegates her ARID, namely, allows another party to send a communication request using her ARID, with proving the chain of authorizing delegation. If the principal wants to delegate her ARID to her assistant or friend, she can do that at her own risk. This conflicts SEC-REQ-5.

• No need for binding an attribute credential to the signaling path of a communication. An ARID is used end-to-end, namely between an originator and the recipient of a communication request while its signaling path is established hop- by-hop through email servers or SIP proxy servers. Since binding an ARID to the signaling path does not enhance any security features, this mechanism does not need such binding.

• No need for binding an attribute credential to a CEID. An email message has a global unique ID in the Message-ID header field and a SIP session can be identified by the set of values from the Call-ID header field, the From header field and its tag, and To header field and its tag. Embedding such a unique ID for a communication request into an ARID does not help to prevent replay attacks. This is due to the fact that when an ARID is stolen or received, it is likely that the communication request message itself is also stolen or received (e.g., an attack by forwarding a received ARID). Thus, this binding is useless for enhancing security. Instead, such a binding would conflict with the privacy requirement, by enabling to link between an ARID and a communication request.

8.4.3 Privacy Requirements

Among the security requirements above, data confidentiality and restricting relying parties, overlap with privacy properties. The remaining privacy requirements are as follows:

PRIV-REQ-1: Untraceability of communication history by issuer. The mecha- nism must allow a principal to specify relying parties without revealing their CEIDs to the issuer. The mechanism should minimize the amount of communication history collected by the issuer.

This requirement contraint is relaxed by one of the requirement excluded because we value the ease of deployment over further privacy enhance- ment. As described below, there is no need for untraceability of the use of attribute credentials by issuer.

PRIV-REQ-2: Selective disclosure of attributes. The mechanism must allow the principal to specify the set of her attributes that she wants to disclose for each communication session.

We intentionally omit the following requirements since we prioritize the ease of deploy- ment over further privacy enhancement.

• No need for untraceability of the use of attribute credentials by issuer. The mechanism should minimize the principal’s activity, for example, when an attribute credential is used, revealed to the issuer, but not prioritize over the ease of deployment. This relaxes the constraint of PRIV-REQ-1.

In our service architecture using online validation of ARIDs on the issuer or the AVS, the AVS can collect and trace whether or not an ARID is used, and if so, when and from which IP address.

• No need for unlinkability between issuance and use of an attribute creden- tial. This privacy property is part of untraceability of the user of attribute credentials considering the scenario where the issuer and a relying party are the same entity.

As described above, as long as this mechanism offer online validation of ARIDs on the issuer or the AVS to the relying parties, the AVS can link the issuance of an ARID and its use for activity analysis purposes, for example.

IDENTIFY GOOD COMMUNICATION REQUESTS 124

F6: HTTP GET with ARID and access code

Message Exchanges

F5: SIP INVITE with ARID and a secret that is used for generating the access code

Alice

Caller: Principal Attribute Validation Server (AVS): Issuer BobCallee: Relying Party

F7: HTTP 200 OK with user attributes F1: HTTP POST with disclosure mode and access code

F8: SIP 200 OK (or 403 Forbidden)

Assesses the value of the call based on the caller’s attributes 11 Wants to make a call to Bob providing her attributes members.ieee.org sips:[email protected] tel:+12345678 F2: HTTP 401 Unauthorized F4: HTTP 200 OK with ARID

F3: HTTP POST with disclosure mode and access code

If ARID includes a trusted server’s URI

Note that SIP proxy servers and messages to and from them are omitted since they are not affected by this mechanism.

Figure 8.2: Message exchanges for validating the caller’s attributes using ARID

This privacy property means that a relying party cannot link among two or more uses of an attribute credential by the principal.

Given that an ARID is designed for the relying party (callee) to filter communication requests based on the attributes of the principal (caller), this privacy requirement is meaningless.

8.5

Procedures for a Call using SIP

Figure 8.2 illustrates message exchanges among a caller acting as the principal, the callee playing the role a relying party and the AVS (i.e., the issuer) for the following procedures:

• Obtaining an ARID (messages F1 - F4);

• Sending the ARID to the callee when making a call using SIP (message F5);

• Validating the ARID to retrieve user attributes (messages F6 and F7);

Before explaining each procedure, we describe how the AVS typically generates an ARID. We then explain the first three procedures mainly for a call using SIP since the last proce- dure, responding to the call request includes no ARID related information and requires no special considerations.