[RFCs/IDs] [Plain Text] [Nits]
Versions: 00
SIP H. Kupwade Patil, Ed.
Internet-Draft Southern Methodist University
Intended status: Experimental D . Willis
Expires: August 20, 2008 Softarmor Systems LLC
February 17, 2008
Identity Based Authentication in the Session Initiation Protocol
draft-kupwade-sip-iba-00
Status of this Memo
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 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 1]
Internet-Draft Identity based authentication in SIP February 2008
comparable to that of certificate-based authentication while
preserving the operational simplicity of shared-secret techniques.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Primer on on Identity Based Cryptography . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Key Distribution Using Byoungcheon Lee et al's
algorithm . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Single Domain Signatures Using Hess's Algorithm . . . . . 8
2.4. Heirarchical Domain Signatures Using Lynn's Algorithm . . 9
2.5. Single Domain Signcryption Using Gentry and
Silverberg's Algorithm . . . . . . . . . . . . . . . . . . 9
2.6. Heirarchical Domain Signcryption Using Chow et. al's
Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Identity Based Authentication in SIP . . . . . . . . . . . . . 11
3.1. Sample SIP Messages . . . . . . . . . . . . . . . . . . . 13
4. Performance of Identity Based Authentication in SIP . . . . . 16
5. Revocation in Identity Based Systems . . . . . . . . . . . . . 17
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Kupwade Patil & Willis Expires August 20, 2008 [Page 2]
Internet-Draft Identity based authentication in SIP February 2008
1. Introduction
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].
2. A Primer on on Identity Based Cryptography
Kupwade Patil & Willis Expires August 20, 2008 [Page 3]
Internet-Draft Identity based authentication in SIP February 2008
2.1. Overview
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 4]
Internet-Draft Identity based authentication in SIP February 2008
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 5]
Internet-Draft Identity based authentication in SIP February 2008
++++++++++++++++++
|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
Kupwade Patil & Willis Expires August 20, 2008 [Page 6]
Internet-Draft Identity based authentication in SIP February 2008
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]
2.2. Key Distribution Using Byoungcheon Lee et al's algorithm
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,
o Bilinear: Let x_1, x_2 and y belong to G_1. Then e(x_1 + x_2, y)
= e(x_1, y).e(x_2, y)t
o Non-degenerate: There exists x belongs to G_1 and y belongs to G_1
such that e(x, y) NOT EQUAL 1
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 7]
Internet-Draft Identity based authentication in SIP February 2008
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]
2.3. Single Domain Signatures Using Hess's Algorithm
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)
Kupwade Patil & Willis Expires August 20, 2008 [Page 8]
Internet-Draft Identity based authentication in SIP February 2008
2.4. Heirarchical Domain Signatures Using Lynn's Algorithm
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
2.5. Single Domain Signcryption Using Gentry and Silverberg's Algorithm
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)
Kupwade Patil & Willis Expires August 20, 2008 [Page 9]
Internet-Draft Identity based authentication in SIP February 2008
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)
2.6. Heirarchical Domain Signcryption Using Chow et. al's Algorithm
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,
Kupwade Patil & Willis Expires August 20, 2008 [Page 10]
Internet-Draft Identity based authentication in SIP February 2008
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 )
3. Identity Based Authentication in SIP
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 11]
Internet-Draft Identity based authentication in SIP February 2008
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.
Kupwade Patil & Willis Expires August 20, 2008 [Page 12]
Internet-Draft Identity based authentication in SIP February 2008
3.1. Sample SIP Messages
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 13]
Internet-Draft Identity based authentication in SIP February 2008
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 14]
Internet-Draft Identity based authentication in SIP February 2008
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 15]
Internet-Draft Identity based authentication in SIP February 2008
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
4. Performance of Identity Based Authentication in SIP
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
Kupwade Patil & Willis Expires August 20, 2008 [Page 16]
Internet-Draft Identity based authentication in SIP February 2008
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
5. Revocation in Identity Based Systems
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.
Kupwade Patil & Willis Expires August 20, 2008 [Page 17]
Internet-Draft Identity based authentication in SIP February 2008
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.
6. Conclusion
The advantages with the proposed methods are:
1. Key size: Elliptic-curve cryptography arguably provides
equivalent security with smaller operands than the RSA technique
typically used with [7]. This provides some advantage for
resource-constrained environments such as mobile telephones. It
also reduces the cryptographic load on large-scale devices doing
frequent authentication checks.
2. Key discovery: Callers can generate the public key of the callee
from the identity (SIP URI) of the callee and vice versa. This
eliminates a requirement for a key discovery mechanism using
external sources, making deployment significantly easier.
3. Certificate validation: As a result caller or callee need not go
through the complex path construction process to retrieve the
public keys of a chain of CAs from the public key depositories
which are controlled by the respective CAs. This allows
deployment in a peer-to-per modality without a need to route SIP
messages through a centralized identity service or trust peer
nodes to operate as identity services.
4. Revocation: The ease of minting new identities and discovering
keys allows short-lived identities, reducing the need for
certificate revocation lists and the checking thereof. This
Kupwade Patil & Willis Expires August 20, 2008 [Page 18]
Internet-Draft Identity based authentication in SIP February 2008
offers very large operational advantages in resource constrained
environments.
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.
7. References
7.1. Normative References
[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
Kupwade Patil & Willis Expires August 20, 2008 [Page 19]
Internet-Draft Identity based authentication in SIP February 2008
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
7.2. Informative References
[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.
Kupwade Patil & Willis Expires August 20, 2008 [Page 20]
Internet-Draft Identity based authentication in SIP February 2008
[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/)
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
This entire document is a discussion of security considerations.
Authors' Addresses
Harsh Kupwade Patil (editor)
Southern Methodist University
Dallas,
US
Phone:
Email: hkupwade@smu.edu
Kupwade Patil & Willis Expires August 20, 2008 [Page 21]
Internet-Draft Identity based authentication in SIP February 2008
Dean Willis
Softarmor Systems LLC
3100 Independence Pkwy #311-164
Plano, TX 75075
US
Phone:
Email: dean.willis@softarmor.com
Kupwade Patil & Willis Expires August 20, 2008 [Page 22]
Internet-Draft Identity based authentication in SIP February 2008
Full Copyright Statement
Copyright (C) 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kupwade Patil & Willis Expires August 20, 2008 [Page 23]
Html markup produced by rfcmarkup 1.70, available from
http://tools.ietf.org/tools/rfcmarkup/