Identity based Authentication in Session Initiation. Session Initiation Protocol

(1)

11.

Identity

based

Authentication

in

Session

Initiation

by

Harsh

Kupwade

Southern

Methodist

University

Dean

Willis

Softarmor

LLC

Thomas

M. Chen

Swansea

University

Nhut

Nguyen

SamsungTelecommunications

Session

Initiation

Protocol

2.INVITE 5.100Trying 1.IN VITE 3.10 0Tr ying 8.18 0Rin ging 200 OK 7.180Ringing 10.200OK 12.ACK 13.MediaSession 14.Bye 15.200OK 4. IN VITE 6. 18 0_Rin gin_g 9. 20 OK 0

[RFC 3261] J. Rosenberg et. al ,“Session Initiation Protocol” IETF RFC 3261

1

(2)

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

INVITE

message

in

SIP

INVITEsip:[email protected]/2.0

Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bK776asdhds Max‐Forwards:70

To:Bob<sip:[email protected]>

From:Alice<sip:[email protected]>;tag=1928301774

Spoofed

Call‐ID:[email protected]

CSeq:314159INVITEContact:<sip:[email protected]> Content‐Type:application/sdpContent‐Length:142 (Alice'sSDPnotshown)

[RFC 3261] J. Rosenberg et. al ,“Session Initiation Protocol” June 2002

RFC

4474

INVITEsip:[email protected]/2.0

Contact:<sip:[email protected]> Identity: "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" Identity‐Info:<https://atlanta.example.com/atlanta.cer>;alg=rsa‐sha1 Content‐Type:application/sdp Content‐Length:147 (Alice’sSDPnotshown)

[IETF RFC 3261] C. Jennings and J. Peterson ,“Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) ” August 2006

3

(3)

We

cannot

apply

RFC

4474

to

SIP

responses

• Response

messages

cannot

be

challenged.

• SIP

response

messages

may

not

encode

the

identity

of

the

responder

5 [RFC 3261] J. Rosenberg et. al ,“Session Initiation Protocol” IETF RFC 3261

Atlanta.com Proxy 1.IN VITE Biloxi.com Proxy 4.Fa lsified 200 OK 4.INVITE 3.Falsified 200OK

Rogue

Proxy

sends

a

falsified

200 OK

7.ACK MediaSession 6 Rogue Proxy Trudy

(4)

Trudy

sends

a

falsified

200 OK

message

to

Alice

SIP/2.0200OK

Via:SIP/2.0/UDPserver10.biloxi.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3 Via:SIP/2.0/UDPbigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

;received=192.0.2.2

Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKnashds8;received=192.0.2.1 To:Bob<sip:[email protected]>;tag=a6c85cf

From:Alice<sip:[email protected]>;tag=1928301774 Call‐ID:a84b4c76e66710

CSeq:314159INVITE

Contact:<IPaddressoftheRogueProxy>

Content‐Type:application/sdpContent‐Length:131 v=0

o=bob28908445272890844527INIP4client.biloxi.example.com s=‐

c=INIP4<IPAddressoftheRogueProxy> t=00

m=audio49172RTP/AVP0

a=rtpmap:0PCMU/8000 7

Approach:

Transform

Response

Identity

problem

into

Connected

Identity

Problem

2.INVITE 1.IN VITE 5.200OK 6.20 0OK 8.INVITE 9.IN VITE 10. 200 OK 11.200OK 3. IN VITE 4. 20 0_OK 7. IN VITE 12. 200 OK

Messages 1-3 convey Alice’s Identity to Bob

Messages 7-9 convey Bob’s Identity to Alice

8 J. Elwell, “Connected Identity in the Session Initiation Protocol (SIP)” IETF draft

(5)

Unanticipated

Response

Problem

1.IN VITE 3.IN VITE 2.INVITE Bobnot availablefora 4.20 0 OK 5.200OK 6.20 0OK

?

SIP/2.0200OK From:<sip:[email protected]>;tag=13adc987 To:<sip:[email protected]>;tag=2ge46ab5 ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Contact:<sip:[email protected]> ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Carol week

Drawbacks

• Self

signed

certificates

• Dependence

on

PKI

– Discoveryofapublickeycertificate [ Linn,Branchaud04] – Complexpathconstructionprocess

INVITE withthe Identityfield

How

do

we

verify

the

Identity

field

?

Di. Berbecaru, A. Lioy and M. Marian “On the Complexity of Public-Key Certificate Validation, ” in Proceedings of the 4th International Conference on Information Security, Lecture Notes in Computer Science, Springer-Verlag, Vol 2200 pages 183-203, 2001

10 9

(6)

Identity

based

signature

algorithms

Singledomain environment Hierarchical domain environment Hess’sAlgorithm (DigitalSignature) Lynn’sAlgorithm (Signcryption Scheme)

GentryandSilverberg’s algorithm(Digital Signature) Chow’s Algorithm (Signcryption Scheme) 11

Signature

and

Key

Size

160bits

H. Kupwade Patil and D. Willis, “ Identity based authentication in SIP” , IETF draft 2008. 12

Criteria RFC4474 IBSSchemes

SignatureSize 175bytes(sig)+512bytes+ Hess’salgorithm

CAcerts 511bytes

Lynn’s 434bytes

Gentry&Silverberg algorithm

434bytes Chowetal’s algorithm

434bytes

(7)

I

Computational

Time

Scheme Generationtimeinsec Verification timein

sec OpenSSL(RFC4474) 0.109s 0.110s PBClibrary 0.078s 0.051s Hess’salgorithm PBClibrary 0.269s 0.238s Lynn’salgorithm PBClibrary

GentryandSilverberg’s algorithm

0.093s 0.063s

PBClibrary

Chowet.al’salgorithm

0.160s 0.162s

13 H. Kupwade Patil and D. Willis, “ Identity based authentication in SIP” , IETF draft 2008.

IBS

to

Response

Identity

Problem

3.NV ITE 4.20 0 OK Carol Bobwould provide privatekeys foraweekto Carol Bob not availablefora week 2.INVITE 5.200OK 1.IN 6.20 0OK

?

SIP/2.0200OK From:<sip:[email protected]>;tag=13adc987 To:<sip:[email protected]>;tag=2ge46ab5 Identity:<Signcryptedmessage>

Identity‐Info:alg=chow;IBS;sip:[email protected]+Date Content‐Type:application/sdpContent‐Length:131 Contact:<sip:[email protected]>

VITE

14 H. Kupwade Patil and D. Willis, “ Identity based signcryption scheme to the connected identity problem in the SIP”

(8)

1. Requ est f orpr ivate key I D= m+ i I

Key

Distribution

in

IBE

[B. Lee et. al. 2004]

1.Requestforpartial privatekeyX,ID

5.Partialprivatekey

[B.Lee et.al 2004] B. Lee, C. Boyd, E. Dawson, K. Kim, J. Yang and S. Yoo, "Secure Key Issuing in ID‐based Cryptography," in ConferencesinResearchandPracticeinInformationTechnology,2004,vol.32,pp.69‐

74. Key Generator 1 2. 3. 4. 15

Revocation

issues

• Expiration

Key

1.Requestforpartialprivatekey

Generator

X,[email protected]+June2,

2008

2.Partialprivatekey

1

• Using

Universally

Unique

User

ID

(UUID)

KeyGenerator

1

3. Digital

Signature

+

UUID

4.Publickey= [email protected]+ UUID 16 (alice @at lanta .co UUID (a) 2.Pr vate key D