| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2008.
Session Initiation Protocol is the Internet Engineering Task Force's standard for multimedia communications in an IP network. Authentication in SIP has been a major concern and most of the existing authentication mechanisms in SIP are dependent on public key infrastructure (PKI) or shared secrets (passwords).This document proposes new authentication schemes in SIP using identity-based signature and signcryption schemes. This approach provides security comparable to that of certificate-based authentication while preserving the operational simplicity of shared-secret techniques.
1.
Introduction
2.
A Primer on on Identity Based Cryptography
2.1.
Overview
2.2.
Key Distribution Using Byoungcheon Lee et al's algorithm
2.3.
Single Domain Signatures Using Hess's Algorithm
2.4.
Heirarchical Domain Signatures Using Lynn's Algorithm
2.5.
Single Domain Signcryption Using Gentry and Silverberg's Algorithm
2.6.
Heirarchical Domain Signcryption Using Chow et. al's Algorithm
3.
Identity Based Authentication in SIP
3.1.
Sample SIP Messages
4.
Performance of Identity Based Authentication in SIP
5.
Revocation in Identity Based Systems
6.
Conclusion
7.
References
7.1.
Normative References
7.2.
Informative References
8.
IANA Considerations
9.
Security Considerations
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
Session Initiation Protocol (SIP, RFC 3261 [1]) is an application layer control protocol for creating, modifying and terminating sessions between one or more user agents. SIP messages may be exposed to a variety of security threats and attacks. One important security issue faced by SIP is authenticating the identity of the sender of a SIP message. Current solutions are based on a variety of signature methods. The most common approach is to use a shared secret to digest the message using HTTP Digest Authentication, [15]. Another technique, called "SIP Identity" involves signing a fixed subset of the message using a certificate [19]. The certificate used for this signing may be the sender's or may belong to an identity service which has presumably used some other means to authenticate the sender. A primary constraint of this approach is that the recipient must posses (or be able to obtain) the public key component of that certificate in order to validate the signature. This requirement has presumably influenced the low adoption rate of the technique. A potential certificate discovery mechanism is proposed in [14].
Another alternative is to apply a "signcryption" technique to selected elements of the message. The main goal of signcryption schemes is to provide authenticity and confidentiality in one logic. This also requires key management, but can be combined easily with identity-based cryptosystems, allowing end users can to generate public keys from a well-known identities. This document illustrates one approach for adapting SIP Identity [7] to take advantage of signcryption using identity based techniques. This document introduces the concept of Identity based cryptography in Section 2 , describes the key distribution process proposed by Byoungcheon Lee et al. in Section 2.2, describes Hess's algorithm which is used to generate the digital signature scheme in a single domain environment in Section 2.3, describes Gentry and Silverberg's algorithm for generating digital signatures a hierarchical domain environment in Section 2.5 , describes Lynn's signcryption scheme for generating a signcrypted message in a single domain environment in Section 2.4, and describes Chow et al 's signcryption scheme for a hierarchical domain environment 2.6. After establishing these basic techniques, the document then describes a procedure by which identity based authentication can be applied to SIP by extending the mechanism of RFC 4474 [7].
| TOC |
| TOC |
The concept of identity based cryptography was first proposed by Shamir in 1984 [18]. The basic idea behind an identity based cryptosystems is that end users can choose an arbitrary string (example: their email address or SIP Uniform Resource Identifier (URI) or IP address) which represents their identity to compute their public key. Thus they do not need digital certificates from a Certificate authority (CA). The private keys paired to the identity based public keys are distributed by some trusted third-party Private Key Generator (PKG). Figure 1 illustrates the key distribution process proposed by Byoungcheon Lee et al in the single domain environment [8].
++++++++++++++++++
|Root Private Key|
| Generator |
++++++++++++++++++
|
|
Alice | Bob
| | |
|Request for | |
|Partial private | |
|key F1 | |
|--------------> | |
| | |
| | |
| Partial private| |
| F2 Key| |
| <--------------| |
| | |
| | |
| | |
| | |
| | Request for|
| | Partial private|
| | F3 key|
| | <--------------|
| | |
| | |
| |Partial private |
| |Key F4 |
| |--------------> |
Figure 1
Alice and Bob pick their secrets and compute their blinding factors. They then send a request for a partial private key to the domain's PKG along with the blinding factor. The credentials that the PKG would use to verify the authenticity of an end user's identity(Alice or Bob's identity) is outside the scope of this document. The PKG sends back their respective partial private keys and the end users generate their private keys from their secrets. An interceptor or an eavesdropper will not be able to generate the private key as he has no knowledge of the secret that was chosen by Alice or Bob. Hence there is a secure key exchange between the PKG and the end users. If Alice would want to authenticate herself to Bob, then she could either generate a digital signature using Hess's algorithm or a signcrypted message using Lynn's algorithm and then send it to Bob [9],[10]. Bob would use Alice's identity to generate her public key and then verify the digital signature or the signcrypted message. Signcrypted messages can only be verified by the intended recipient as he would use his own private key along with sender's public key to validate the ciphertext. Identity based authentication can be easily extended to a two level hierarchical domain environment. Figure 2 describes the key distribution process for a two level hierarchical system
++++++++++++++++++
|Root Private Key|
| Generator |
++++++++++++++++++
|
|
|
PKG1 | PKG2
| | |
| F1 | |
|-------------->| |
Alice | F2 | | Bob
| |<--------------| | |
| | | F3 | |
| | |<--------------| |
| | | F4 | |
| | |-------------->| |
| | | | |
| F5 | | | |
|-------------->| | | |
| F6 | | |
|<--------------| | F7 |
| | |<--------------|
| | | F8 |
| | |-------------->|
| | | |
| | | |
| | | |
| | | |
| | | |
F1,F3,F5,F7 - Requst for partial private key
F2,F6,F4,F8 - Partial Private Key
Figure 2
Alice belonging to Atlanta.com would want to communicate with Bob belonging to Biloxi.com. The PKGs serving Alice and Bob would procure their private keys from a Root PKG (R-PKG) using Byoungcheon Lee et al.'s algorithm [8]. Alice would then use Gentry and Silverberg's algorithm to generate a digital signature or Chow et al.'s algorithm to generate a signcrypted message [16],[17]
| TOC |
Shamir constructed an Identity-Based Signature (IBS) scheme using the existing RSA function [19], but he was unable to construct an Identity-Based Encryption (IBE) scheme, which became a long lasting open problem [18]. Recently in 2001, Shamir's open problem was independently solved by Boneh and Franklin using the concept of bilinear maps [5]. Hence, it led to a new area of research where many identity based digital signature schemes were proposed using the concept of bilinear maps. Below is a brief review of the private key distribution process proposed by Byoungcheon Lee et al [8].
Let H_1,H_2 and H_3 are three hash functions such that
H_1 : {0, 1}^l-->G_1 where l is the length of the plain text.
H_2 : {0, 1}^l * G_2 --> Z_q where Z_q = Z/qZ denotes integers mod q where q is a large prime. Therefore Z_q denotes the group {0, 1, 2, .........., q -1} and (Z_q)^* = Z\{0}.
H_3 : G_2 --> (Z_q)^*
The PKG specifies two groups G_1 and G_2 of order q, where G_1 is an additive group and G_2 is a multiplicative group and a bilinear map e : G_1 * G_1 --> G_2 between the group which satisfies the following properties,
In fact G_1 will be a point subgroup on an elliptic curve over a finite field and G_2 is a subgroup of a cyclic group of a larger finite field. The pairings are derived from the Weil or Tate pairing [5].
The PKG chooses a private key s_0 belong to Z*q and computes the master public key
P_0 = s_0.P where P belong to G_1
The security of the master public key is dependent on the elliptic curve discrete log problem [6]. It publishes the description of the groups G_1 and G_2, the bilinear map e,hash functions (H_1, H_2 and H_3), public key P_0 and the group element P .Alice with identity ID_A chooses a random secret x belong to Z*q and computes a blinding factor X = xP . She then requests the PKG to issue a partial private key by sending X and ID_A.
The PKG then validates Alice's identity and computes the public key of Alice as
Q_ID_A = H_1(ID_A)
It computes a blinded partial private key as Q_bl_A = H_3[e(s_0X, P_0)]s_0Q_ID_A
It then generates a signature Sig(Q_bl_A) for integrity protection. Sig(Q_bl_A) = soQ_bl_A
It sends Sig(Q_bl_A) and Q_bl_A to Alice. Alice verifies the signature using the below mentioned formula, e(Sig(Q_bl_A), P ) ?= e(Q_bl_A , P_0)
and finally retrieves her private key D_ID_A by unblinding Q_bl_A as follows D_ID_A = Q_bl_A H_3[e(P_0, P_0)x]
| TOC |
Alice will then use the algorithm proposed by Hess to generate the digital signature . She would pick her secret
k BELONGS TO (Z_q)^*, and then calculate
r = e(P_1, P )^k where P_1 BELONGS TO G_1
v = H_2(m, r) where m is the message
u = v*D_ID_A + k*P_1
She would then send the signature (u, v) to Bob. Bob would calculate r from (u, v).
r = e(u, P ).e(H_1(ID_A), -P_0)v And validate the signature if
v ?= H_2(m, r)
| TOC |
Let
H_4 : {0, 1} * {0, 1} --> Z_q
H_5 : Z_q * G_2 --> {0, 1}*
H_6 : {0, 1}l --> {0, 1}*
Alice would compute
q = H_4(k, m)
and
w = e(D_ID_A , Q_ID_B )
Alice would send the signcrypted message {U, V, W } to Bob where
{U, V, W } = { q , E_n_(H_5[q,w]) (k) , E_n(H_6[k])(m) }
En(Key) refers to encryption using AES algorithm [22]
Bob would decrypt the message m as shown below
e(Q_ID_A , D_ID_B) = w
D_n_(H_5[U,w])(V) = k
D_n_(H_6)[k](W) = m
| TOC |
Let the Root PKG's master private key be M_s BELONGS TO (Z^*)_q and the master public key be
Q_0 = M_s*P where P BELONGS TO G1
PKG at Atlanta.com with identity (ID_1) and the PKG at Biloxi.com with identity (ID_2) generate their private keys D_ID_1and D_ID_2 using the Byoungcheon Lee et al's algorithm respectively.
Let the public keys of PKG at Atlanta.com and the PKG at Biloxi.com be Q_ID_1 = H_1(ID_1)
and Q_ID_2 = H_1(ID_2)
The PKG at Atlanta.com would pick a secret s_1 BELONGS TO (Z^*)_q and computes the blinded partial private key for Alice as show below
Q_bl_A = H_3[e(s_1*X, Q_1)]S_A where
S_A = D_ID_1 + s_1*Q_ID_A The PKG at Atlanta.com would generate a public parameter Q_1 = s_1*P
Alice would generate her private key as shown below
D_ID_A = (Q_bl_A) /(H_3[e(Q_1, Q_1)^x])
Similarly the PKG at Biloxi.com would pick a secret s_2 BELONGS TO (Z^*)_q and compute the blinded partial private key Q_bl_B and the public parameter Q_2.
She would then generate the signature as shown below
Sig_gs = S_A + k*P_M
where
P_M = H_1(m)
She would calculate the public parameter Q_M = kP
She would send Sig_gs, Q_0, Q_1 and Q_M to Bob. Bob would verify the signature as show below
e(P, Sig_gs) ?= e(Q_0, Q_ID_1).e(Q_M , P_M ).e(Q_1, Q_ID_A)
| TOC |
We follow the hierarchical architecture as described in Section 2.2 E
Let
H_7 : G_2 --> {0, 1}^*
Alice would generate the signature
Sig_c = D_ID_A + kP_M
and compute
g = e(Q_0, kQ_ID_2)
She would generate the signcrypted message as shown below,
U_1 = Q_M , U_2 = k*Q_ID_B , V = E_n_H_7[g](m|| Si g_c||ID_B), W_1= Q_0, W_2 =Q_1, W_3 =Q_M
Alice would send {U_1, U_2, V, W_1, W_2, W_3} to Bob.
Bob would compute e(U_1, D_ID_B ) / e(Q_2, U_2) = g
and then decrypt V as , D_n_H_7[g](V) = (m|| Si gc||IDB)
He would then verify the signature as shown below,
e(P, Si g_c).e(W_2, Q_ID_A) ?= e(W_1, Q_ID_1 )*e(W_3, P_M )
| TOC |
RFC 4474 [7] provides a model for signing a SIP request using conventional public-key techniques. The signature itself is carried in a header field called "Identity". A related header field called "Identity-Info" conveys supporting information, including a location from which the certficicate used to create the signature may be retrieved if the recipient does not yet have it. This document re-uses those header fields by following the extension sytnax of RFC 4474. The signed or singcrypted text is transmitted in the "Identity" header field, as in RFC 4474. The "Identity-Info" header field is extended to allow the recipient to discover that the signature being presented is identity-based and determine which algorithm was used in the calculation. The syntax as used in this document is believed to be slightly flawed but could be reasonably adapted for consistency with RFC 4474. Note that the nature of the identity relationship here allows meaningful use of the Identity header in response messages as well as request messages. The "From" header field of each request encodes the identity used for message signing, and the "To" header field encodes the target identity used for signcryption (is signcryption is used) as well as the identity from which responses will be anticipated if this technique is used to protect messages sent in response. One open issue is whether there may be multiple root PKG namespaces potentially valid for a given domain. If so, then the "Identity-info" header field will need to encode a pointer into the PKG namespace.
Let us consider the case where Alice belonging to example.com with a SIP URI sip:alice@example.com would want to authenticate herself to Bob (sip:bob@example.com). She would compute the digital signature using Hess's algorithm [described in section 2.3] or the signcrypted message using Lynn's algorithm [described in section 2.4]. The message m is calculated by hashing the SIP header fields of the INVITE message as recommended in RFC 4474 [7]. In case of a hierarchical domain environment Alice belonging to atlanta.com with a SIP URI (sip:alice@atlanta.com) would want to authenticate herself to Bob belonging to biloxi.com (sip:bob@biloxi.com).
The following text includes several sample SIP messages signed using this technique. The first is an INVITE message with the digital signature generated using Hess's algorithm. The second uses a signcrypted header field generated using Lynn's algorithm in a single domain environment. The third sample is an INVITE message with a signature generated using Gentry and Silverberg's algorithm, and the fourth is showas a signcrypted headerfield generated using Chow's algorithm in a two level hierarchical domain environment. As with RFC 4474, the contents of the Identity header field are encoded using the Base64 algorithm [21]. Although these sampel messages are all requests, the technique can be applied to responses, allowing recipient Bob to authenticate himself to Alice by inserting appropriate Identity and Identity-Info header fields into the response message 200 OK.
| TOC |
INVITE sip:bob@example.com SIP/2.0 Max-Forwards: 70 To: Bob <sip:bob@example.com > From: Alice < sip:alice@example.com> tag=1928301774; Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: < sip:alice@pc33.example.com > Identity: "dSA9IFsxNjU4NjA5NDU1ODMyMzk3OTQwM5NTYzO TQwMzI0NDgNCjY1Mzc2MTAwOTI3NzkyNDgwMjYz NjgxODQxMTkwNzk3MzIwMTA0OTgxNDAxDQo5MjY 4Nzk4MjU1MDY2ODU5MjQ0MTcxMTA2NjE0ODQwOD M0OTE1MzQyMzE0MQ0KMDcwODk2MDcyNjIyNzU4N DA4OTQ0ODMwNjA4MjExMzUgLCA4NDDM4ODU3NDE 0MA0KNzYwNjgzMjY1MjM0MDg1ODMzMjA2MDc0Nj A3NTgwNTEwOTQNCY5NzI4MDgwODjI4NjA0MzAzN DQ3NjczMDg0OTU0MDI1NzI3MDgyNzk5MTE4OTQz MDU1MDM3DQo3MDQ5NjkxMjkyMjQxNw0KNzgyODM 4NjE4NDFdDQp2ID0gNDUwOTY5MjM0MjQxODQyMT YzODQ0MjkxNTI1NTk3MzMwNjMyOTAzNTcNCjAwN Dg3NzUNCg==" Identity-Info: IBS; alg=hess Content-Type: application/sdp Content-Length: 142 Alice's Session Description Protocol (SDP) not shown) Figure A1: SIP INVITE message with the digital signature using Hess algorithm
INVITE sip:bob@example.com SIP/2.0 Max-Forwards: 70 To: Bob <sip:bob@example.com > From: Alice < sip:alice@example.com> tag=1928301774; Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: < sip:alice@pc33.example.com > Identity: "Wzc5NTk5NDM0NTk2Njg5OTMzMTU1OTQwNTQ1ODU 0Nzc2NDMxNzk0OTQ1NDQ5MTQwOE0ODE2NA0KMTY 5NTc5ODA3ODg1NjQxODU2NjQxNzIzNjAxMDQwNz M4NDUyNzAwOTEwMzYwLDM4ODYzNTY5Mw0KMTIzN TkzODA5NzEzODg3NzkxNTM3NjMxMTU3OTcyNDYx MzU3NjYwMTA2MDQzMTM3NDIzNzE3Mw0KMDk1MjU wNDg2NjkxMTYwMzA3NjU1MzMzOTUwMDI3MTI4Nj M2NzUyNjIyNDY1MDM4NjM5ODeODU2NjQxNzIzNj AxMDQwNzM4NDUyNzAwOTEwMzYwLDM4ODYzNTDA5 NzEzODg3NzkxNTM3NjMxMTU3OTcyNTM3NDIzNzE 3Mw0KMDk1MjUwNDg2NjkxMTYw0KMTIzNTkzODA5 NzEzODg3NzkxNTM3NjMxMTU3OTc== Identity-Info: IBS; alg=lynn Content-Type: application/sdp Content-Length: 142 Alice's Session Description Protocol (SDP) not shown) Figure A2: SIP INVITE message with the digital signature using Lynn's algorithm
INVITE sip:bob@atlanta.com SIP/2.0 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice < sip:alice@atlanta.com> tag=1928301774; Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: < sip:alice@pc33.atlanta.com > Identity: "WzQ4M4MjE4MTA0MDEwNzQyNjQ1OTcNjYxMz4MjE zA5MU0Mc1MDAxMjMwDQo3ODIzMjU4MTAzk0MTQw Njg0MjA4NDDUwgwMzc2ODMNCjEyNjgwNTMzQ1MT cxNzA2NzMU4Mzc2OTc2MMjQ0NjEyODQyNzkwNzY s1NjUxMg0KNTAwMTczNNDk5MzIzODM1Tc2DUxND MxOTE4OTU3MzQ4NzM1NzEyNjMwMTI0NDkyNzM0M 4ODgzjk3MDA0OTg0OTg2MzI3DQo2NTgwNzI3ODc 0Mzc3MzYNjQ1OTcxNDU4MTI2MDE0OTc4NDY1Njk 3QyNzkwNzYs1NjUxMg0KNTAwMTczNNDk5MzIzOD MjgwNTMzQ1MTcxNzA2NzMU4Mzc2OTc2MMjNDMxO TE4OTU3MzQ4NzM1NzEyNjMwMTI0NDkyNzM0M4E4 OTU3MzQ4NzM1NzEyNjMwMTI0N===" Identity-Info: IBS; alg=gentrysilverberg Content-Type: application/sdp Content-Length: 142 Alice's Session Description Protocol (SDP) not shown) Figure A3: SIP INVITE message with the digital signature using Gentry and Silverberg's Algorithm
INVITE sip:bob@atlanta.com SIP/2.0 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice < sip:alice@atlanta.com> tag=1928301774; Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: < sip:alice@pc33.atlanta.com > Identity: "WzQ4MDQ0MDk3NTk5NTYzMzgyNjUzNjk2YxMz4MjE NzczNjgxNjYxMz0MDEwNzQyNjQ1OTcxNDU4MTI2w MDE0OTc4NDY1Njk3NzIyMzA5MgwMzc2ODMNCj1MT EyNjgwNTU4Mzc2OTc2MDUwMzQ1MTcxNzA2NzMNzY DUxNDMxOTE4OTU3MzQ4NzM1NzEyNjMwMTI0NUxND DkyNzM0MTc2jk3MDA0OTg0OTg2MzI3DQo2NTgw0M NzI3ODc0Mzc3MzY4ODgzDk5MzIzODM1MjQ1NjUxc Mg0KNTAwQwNjg0MjA4NDc1MDAxMjMwDMNCjE1Njk yNjgwNTU4Mzc2OTc2MDUwMc2ODMNCjEyNjgwNzOD TU4Mzc2OTc2MDUwMzQ1EwNzQyNjQ1OTcxNDU4MxO MTI2MDE0OTc4NDYxNDMxOTE4OTU3MzQ4NzM1M4E4 NDMxOTE4OTU3MzQ4NzM1NzEyNjMwMTI0NDkyNzM0 NzEyNzYsNDk5MzIzODM1MjQ1NjUxMg0K==" Identity-Info: IBS; alg=chow Content-Type: application/sdp Content-Length: 142 Alice's Session Description Protocol (SDP) not shown) Figure A4: SIP INVITE message with the digital signature using Chow's Algorithm
| TOC |
The authentication mechanism discussed in this document allows the end users to directly authenticate each other. This scheme also reduces the burden on the SIP proxies as they need not play the role of an authenticator. We used the Pairing-based Cryptography Library [24] to generate the identity based signatures/signcryption schemes. We choose pairings of Type A curves because they are fast and are used where the main concern is efficiency. Type A pairings are constructed on the curves y^2 = x^3 + x over the field F_p where p is some prime. We choose the group order to be 160 bits and the order of the base field to be 512 bits. RFC 4474 uses SHA1 hashing algorithm whose output size is 160 bits with RSA as their signing algorithm [7]. We used SHA256 hashing algorithm whose output size is 256 bits with signing algorithms that are dependent on elliptic curve cryptography. Table 1 compares the processing time to generate the digital signatures between our scheme and the scheme proposed by RFC 4474. Times for RFC 4474 were calculated using the OpenSSL library. All message parsing was done by hand.
| Scheme | Generation time in sec | Verification time in sec |
|---|---|---|
| OpenSSL | 0.109s | 0.110s |
| Algorithm 2.3 | 0.078s | 0.051s |
| Algorithm 2.4 | 0.269s | 0.238s |
| Algorithm 2.5 | 0.093s | 0.063s |
| Algorithm 2.6 | 0.160s | 0.162s |
| Table 1: Comparision of CPU time between IBA schemes and RFC 4474 |
We observe a 28.44% decrease in the processing time in generating digital signatures when generated using Hess's algorithm and 14.66% decrease in the processing time when generated using Gentry and Silverberg's algorithm. We also observe a 53.63% decrease in the processing time in verifying the digital signatures when generated using Hess's algorithm and 42.72% decrease in the processing time when generated using Gentry and Silverberg's algorithm. While we observe an increase in processing time when compared to the signcryption schemes, but the signcryption schemes perform both authentication and encryption in one logic. In our scheme the end users need not append their X.509 v3 certificates and hence there is a substantial amount (10 K bytes) of decrease in the payload
| TOC |
In case of PKI, the public key certificates contain a preset expiration date. If the validity date expires, or if the sender (caller) refreshes his private key, then the recipient (callee) would have to obtain a new certificate from a public key repository which would involve the onerous task of certificate path construction and path validation processes.
But in case of Identity based encryption system the sender can generate a public key using the recipient's identity (SIP URI) along with the expiration date. If the date has expired, the recipient needs to obtain a new private key from the PKG. As a result the recipient would clearly by pass the tedious task of obtaining a new public key certificate from a public key repository.
One could make this approach more granular by generating the public key using the recipient's identity along with the current date. In this case it would force the recipient to obtain a new private key every day. If the end user leaves the domain in which he was registered, the PKG is instructed to stop issuing private keys for that end user's SIP URI. As a result
Bob can no longer prove his identity unless he obtains a new private key from the new domain's PKG. But, on of the most prominent features with IBE is that the sender need not communicate with any third party controlled certificate directory to obtain the recipient's public key.
Alice could also generate a unique public key for Bob by concatenating Bob's SIP URI along with a Universally Unique Identifier (UUID) and then generate a digital signature or a signcrypted message [23]. Therefore if Bob wants to verify the signature or decrypt the signcrypted message, Bob would have to request a new partial private key from its domain's PKG.
| TOC |
The advantages with the proposed methods are:
The primary disadvantage of the proposed method relates to the the single-root model of private key generation. There is, however, ongoing research on loosely-coupled heirarchical PKGs that should lead to the alleviation of this constraint. However, in the typical usage scenarios of single and confederated domains, the single-root model is not particularly disadvantageous.
The proposed model seems to be especially well-suited for peer-to-peer SIP environments [ 13], wherein there are no "identity servers" or "trusted proxies" in the traditional sense. The enrollment process can include private key generation, allowing nodes to therafter operate securely using the methodology of this document.
| TOC |
| TOC |
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002
[2] Zheng, Y., "Signcryption and Its Applications in Efficient Public Key Solutions," in Proceedings of Information Security Workshop, 1997, Lecture Notes in Computer Science, vol. 1397, Springer-Verlag, pp. 291- 312, 1998.
[3] Housley, R., Ford, W., Polk, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," IETF RFC 3280.
[4] Pala, M., and Smith, S.W., "AutoPKI: a PKI Resource Discovery System," in European Public Key Infrastructure Workshop, 2007, Lecture Notes in Computer Science, Springer-Verlag, To apper.
[5] Boneh, D. and Franklin, M., " Identity-Based Encryption from the Weil Pairing," SIAM Journal of Computing, vol. 32, no. 3, pp. 586-615, 2003.
[6] Smart, N.P, "The Discrete Logarithm Problem on Elliptic Curves of Trace One," Journal of Cryptology, vol. 12, Springer New York, pp. 193-196, 1999.
[7] Peterson, J. and Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), " IETF RFC 4474.
[8] Lee, B., Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S., "Secure Key Issuing in ID-based Cryptography," in Conferences in Research and Practice in Information Technology, 2004, vol. 32, pp. 69-74.
[9] Hess, F., "Efficient Identity Based Signature Schemes based on Pairings," in Selected Areas in Cryptography: 9th Annual International Workshop, 2002, Lecture Notes in Computer Science, vol. 2595, Springer-Verlag, pp. 310-324, 2003
[10] Lynn, B., "Authenticated Identity-Based Encryption," available at http://eprint.iacr.org/2002/072/.
[11] Gentry, A., and Silverberg, A., "Hierarchical ID-Based Cryptography," in Proceedings of the 8th International Conference on the Theory and Application of Cryptology and Information Security, 2002, Lecture Notes in Computer Science, vol. 2501, Springer-Verlag, pp. 548 - 566, 2002.
[12] Chow, S. , Yuen, T., Hui, L. and Yiu, S., "Signcryption in Hierarchical Identity Based Cryptosystem," Security and Privacy in the Age of Ubiquitous Computing, International Federation for Information Processing, vol. 181, pp. 443-457, Springer Boston, 2005
| TOC |
[13] Bryan, D., Matthews, P., Shim, E., and D. Willis, "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-01 (work in progress), November 2007.
[14] Jennings, C., Peterson, J., and J. Fischl, "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sip-certs-05 (work in progress), February 2008.
[15] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", IETF RFC 2617, June 1999
[16] Salsano, S.,Veltri, L. and Papalilo, D., "SIP Security Issues: The SIP Authentication Procedure and its Processing Load," IEEE Networks, vol. 16, issue 6, pp. 38-44, Dec 2002
[17] Gupta, P., and Shmatikov, V., "Security Analysis of Voice-over-IP Protocols", in 20th IEEE Computer Security Foundations Symposium, 2007, pp. 49-63.
[18] Shamir, A., "Identity-based Cryptosystems and Signature Schemes", Advances in Cryptology: Proceedings of CRYPTO 84, Lecture Notes in Computer Science, vol. 196, Springer-Verlag, pp. 47-53, 1984.
[19] Rivest, R.L, Shamir, A., and Adleman, L.M, "A Method for Obtaining Digital Signa-tures and Public-Key Cryptosystems,", Communications of the ACM , vol. 21, pp. 120-126, ACM NY, 1978.
[20] Secure Hash Standard availabe at http://csrc.nist.gov/publications/fips/fips180-2/fips180- 2withchangenotice.pdf.
[21] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings," IETF RFC 3548, July 2003.
[22] National Institute of Standards and Technology (NIST). FIPS- 197: Advanced Encryption Standard, November 2001, available at http://www.itl.nist.gov/fipspubs/.
[23] Leach, P., Mealling, M. and Salz, R., "A Universally Unique IDentifier (UUID) URN Namespace," IETF RFC 4122, July 2005.
[24] Lynn, B., "Pairing-based Cryptography Library," version 0.4.9. available at http://crypto.stanford.edu/pbc/ (http://crypto.stanford.edu/pbc/)
| TOC |
This memo includes no request to IANA.
| TOC |
This entire document is a discussion of security considerations.
| TOC |
| Harsh Kupwade Patil (editor) | |
| Southern Methodist University | |
| Dallas, | |
| US | |
| Phone: | |
| Email: | hkupwade@smu.edu |
| Dean Willis | |
| Softarmor Systems LLC | |
| 3100 Independence Pkwy #311-164 | |
| Plano, TX 75075 | |
| US | |
| Phone: | |
| Email: | dean.willis@softarmor.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.