Internet Engineering Task Force Manoj Wagle Category: INTERNET-DRAFT Rohit Aradhaya draft-wagle-sip-kerbpki-00.txt Motorola November 10, 2002 Expires: May 10, 2003 An Out-of-Band authentication procedure for SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a out-of-band security mechanisam using Kerberos-PKI for providing end-to-end security between SIP clients. 1 Introduction Currently, SIP (3) specifies use of either HTTP Digest or S-MIME security mechanisam for providing selective security at SIP level. The key generation is not defined and currently not in scope of SIP(3). Both the mechanisam are not fool-proof security mechanisam, One of them only provides an authenciation feature. The transport level security (TLS), is the recommended ("SHOULD") methodlogy in SIP RFC. The TLS provides a mechanisam for generating key and provides hop-by-hop transport level security (i.e. transport payload is secured). The cons. of TLS is that on server side it has to maintain multiple TLS sessions. Any break in session or change in address needs a session re-initiation. If using Public/Private key, the algorithmic procedures are computational heavy, thus makes it less scalable (i.e. with large number of subscriber). Since TLS will be a hop-by-hop security mechansim,TLS will be used between starting Node and first intrim proxy, security for remaining path till the end host may not be TLS and depends on intrim proxy, and there is no binding on it to use TLS. The IPSEC, an application agnostic security at IP level, needs IKE key management to create and maintain secure tunnels between two clients over public internet. The complex nature of IKE makes it more difficult within SIP domain, although it is also recommended("MAY") in SIP(3) RFC. The rest of the section, will define a new mechanisam of security for SIP domain, which provides end-to-end security, characterized by light weight (i.e. less number of key management messages, ticket controlled authentication, and easy to manage/deploy). This mechanisam is based on using KERBEROS-PKI as key management for authenticating the end SIP clients and generating ticket on behalf of server. The SIP client uses that ticket to authenticate itself to the end-server and generates the key, which is used for securing the SIP payload. The message exchanges for key generation and providing SIP level security is detailed in following sections. Expires may 2003 [Page 1] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 2 Terminologies The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the draft (KERB-PKI) or SIP(3). 3. Definitions The following terms are defined and/or additionally clarified: KDC: A Key distribution center, trusted server, which authenticates the client on behalf of the server and provides a ticket SIP-KERBPKI-UA: A SIP Kerberos PKI UA, is a SIP UA enabled with KERBEROS-PKI support for providing end-to-end security. Ticket: A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator. Authenticator: A record containing information that can be shown to have been recently generated using the session key known only by the client and server. Session key: A temporary encryption key used between two principals, with a lifetime limited to definete duration. Client: A process that makes use of a network service on behalf of a user. Server: A particular Principal which provides a resource to network clients. Principal: A uniquely named client or server instance that participates in a network communication. 4. Architecture of KERB_PKI enabled SIP-UA In this section, we present a functional architecture of a SIP UA client enabled with KERB-PKI and an overview of the KERB-PKI based operation for SIP UA's. 4.1 Authentication using KERB-PKI The functional architecture of the SIP-KERBPKI-UA client is shown in the following Figure-1 =============== | Applications| =============== | -------- ---------- API ------------------ |crypto|<--->| SIP-UA | <===>| KERB-PKI Client| -------- ---------- ------------------ | | ---------- ---------- | TCP | | UDP | ---------- ---------- Figure: 1 When a SIP UA wishes to initiate a secure transaction with end SIP UA. It request the KERB-PKI client(via API) to initate a request to pre-provisioned KDC. The request from client will contain the credentials (i.e. certificates) issued by the service provider. The KDC verifies the credenditals and based on the credentials the ticket is issued and responded back by KDC to client, which allows client to access the service over SIP from the remote server. The authentication sequence of message flows between SIP UA and KDC is shown in figure (2) SIP Terminal KDC SIP Server |AS_REQUEST (clnt, srvr,service | | | |-------------------------------->| | |service, dh params, certificates)| | | | | |AS_REPLY (clnt, srvr, enc_tkt, | | Ticket |<--------------------------------|(client authenticated) | Granted |sess_key, dh params, certs) | | | | | |AP_REQUEST(doi,cipher_suite,sha1_hash,enc_tkt,authenticator)| | |---------------------------------|------------------------->| | | | Using |AP_REPLY (doi, cipher_suite, sha1_hash, Assoc_Lifetime, | Subkey |<--------------------------------|--------------------------| final key| srvr_timestamp,subkey) | | is derived| | | |<================ SIP payload is encrypted/authenticated ===| using this generated key. Figure: 2 Expires may 2003 [Page 2] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 The following Figure-3 provides authentication as well as key generation message excahnges, if SIP session is being iniated from server end. SIP Terminal KDC SIP Server | WAKEUP (doi, nonce, appl_srvr_name) |<--------------------------------|--------------------------| | | | |AS_REQUEST (clnt, srvr,service | |If ticket | |-------------------------------->| |available for |service, dh params, certificates)| |appl_srvr_name | | |is valid, then |AS_REPLY (clnt, srvr, enc_tkt, | |this procedure Ticket |<--------------------------------|(client authenticated) |is not done. Granted |sess_key, dh params, certs) | | | | | |AP_REQUEST(doi,cipher_suite,sha1_hash,enc_tkt,authenticator)| | |---------------------------------|------------------------->| | | | Using |AP_REPLY (doi, cipher_suite, sha1_hash, Assoc_Lifetime, | Subkey |<--------------------------------|--------------------------| final key| srvr_timestamp,subkey) | | is derived| | | |<================ SIP payload is encrypted/authenticated ===| using this generated key. Figure: 3 Note: KDC can co-locate with server, only for message exchange clarity it has shown as seperate entity. The KERB-PKI client, provides an out-of-band authentication mechanisam for SIP client. The server does not need to maintain the sessions and it scales with large number of subscribers, because the initial authentication message exchanges happens only when ticket is not valid (i.e. not available for required server, expired or corrupted). 4.2.Kerberos Messages This section depicts relevent kerberos messages for understanding purpose only, for more detail please refer[2]. 4.2.1 AS Request SIP UA Sends this message to Key distribution server (KDC) [Note: may be colocated with the SIP Server]. This message contains (in cleartext) its own identity,the identity of the server for which it is requesting credentials. The preauthentication field of AS Request contains the following asn.1 encoded data structure, where in preauthentication type = 14. PA-PK-AS-REQ ::= SEQUENCE { -- PA TYPE 14 signedAuthPack [0] ContentInfo, } Expires may 2003 [Page 3] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 The type of the ContentInfo in the signedAuthPack is SignedData. The SignedData data type is specified in the Cryptographic Message Syntax, a product of the S/MIME working group of the IETF. The following describes how to fill in the fields of this data: 1. The encapContentInfo field MUST contain the PKAuthenticator and, optionally, the client's Diffie Hellman public value. a. The eContentType field MUST contain the OID value for pkauthdata: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) b. The eContent field is data of the type AuthPack (below). 2. The signerInfos field contains the signature of AuthPack. 3. The Certificates field contains the client's certificate chain.KDC uses the public key from the client's certificate to verify the signature in the request. 4. The public exponent of the Diffie-Hellman key is provided in the subjectPublicKey field of the SubjectPublicKeyInfo and the DH parameters are supplied as a DomainParameters in the AlgorithmIdentitfier parameters. The authpack structure present in econtent, AuthPack ::= SEQUENCE { pkAuthenticator [0] PKAuthenticator, clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL -- if client is using Diffie-Hellman -- (ephemeral-ephemeral only) } pKAuthenticator structure present in AuthPack, PKAuthenticator ::= SEQUENCE { cusec [0] INTEGER, -- for replay prevention as in RFC 1510bis ctime [1] KerberosTime, -- for replay prevention as in RFC 1510bis nonce [2] INTEGER, -- zero only if client will accept -- cached DH parameters from KDC; -- must be non-zero otherwise pachecksum [3] Checksum -- Checksum over KDC-REQ-BODY -- Defined by Kerberos spec; -- must be unkeyed, e.g. sha1 or rsa-md5 } Expires may 2003 [Page 4] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 subjectPublicKeyInfo present in Authpack structure, SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, -- dhPublicNumber subjectPublicKey BIT STRING -- for DH, equals -- public exponent (INTEGER encoded -- as payload of BIT STRING) } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, -- for dhPublicNumber, this is -- { iso (1) member-body (2) US (840) -- ansi-x942(10046) number-type(2) 1 } -- from RFC 2459 parameters ANY DEFINED by algorithm OPTIONAL -- for dhPublicNumber, this is -- DomainParameters } -- as specified by the X.509 RFC 2459 specification. DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor validationParms ValidationParms OPTIONAL } -- as defined in RFC 2459 4.2.2 AS Reply: Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication type, the KDC attempts to verify the client's certificate chain in the request. If a trust relationship exists, the KDC then verifies the client's signature on AuthPack. The KDC also checks that the timestamp in the PKAuthenticator is within the allowable window and that the principal name and realm are correct. KRB_AS_REP, contains a ticket for the client to present to the server, and a session key that will be shared by the client and the server. The session key and additional information are encrypted in the client's secret key. The AS Reply message contains information which can be used to detect replays, and to associate it with the message to which it replies. The KDC encrypts the reply with the Diffie Hellman derived key which is carried in the padata field of the AS Reply message. Expires may 2003 [Page 5] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 The preauthentication field (padata) in AS Reply contains PA-PK-AS-REP ::= CHOICE { -- PA TYPE 15 dhSignedData [0] ContentInfo; } The type of the ContentInfo in the dhSignedData is SignedData. dhSignedData in PA-PK-AS-REP provides authenticated Diffie-Hellman parameters of the KDC. The reply key used to encrypt part of the KDC reply message is derived from the Diffie-Hellman exchange, for details of reply key generation refer [2]. 1. The encapContentInfo field MUST contain the KdcDHKeyInfo as defined below. a. The eContentType field MUST contain the OID value for pkdhkeydata: iso (1) org (3) dod (6) internet (1) security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) b. The eContent field is data of the type KdcDHKeyInfo(below). 2. The certificates field MUST contain the certificates necessary for the client to establish trust in the KDC's certificate based on the list of trusted certifiers sent by the client in the PA-PK-AS-REQ. if SIP client already contains KDC's certificate, this field may be empty. 3. The signerInfos field is a SET that MUST contain at least one member, since it contains the actual signature. KdcDHKeyInfo ::= SEQUENCE { -- used only when utilizing Diffie-Hellman subjectPublicKey [0] BIT STRING, -- Equals public exponent (g^a mod p) -- INTEGER encoded as payload of -- BIT STRING nonce [1] INTEGER, -- Binds response to the request -- Exception: Set to zero when KDC -- is using a cached DH value dhKeyExpiration [2] KerberosTime OPTIONAL -- Expiration time for KDC's cached -- DH value } 4.2.3 AP Request: When a client wishes to initiate authentication to a server, it obtains (either through a credentials cache, the AS exchange) a ticket and session key for the desired service. The client may re-use any tickets it holds until they expire. The client then constructs a new Authenticator from the the system time, its name, and checksum. Expires may 2003 [Page 6] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 The Authenticator is encrypted in the session key and combined with the ticket to form the KRB_AP_REQ message which is then sent to the end server along with any additional application-specific information. AP Request data structure look like apreqmsg ::= SEQUENCE { doi, /* Domain of interpretation */ KRB5_AP_REQ /* asn.1 DER encoded KRB5_AP_REQ structure */ Nonce, Application Specific Data, /* To be defined for SIP Security -TBD */ Num of CipherSuites, CipherSuites, Re establish Flag, sha1hmac hash /* SHA1 HMAC over AP_REQ message */ } 4.2.4 AP Reply: A client's request will include both the authentication information and its initial request in the same message, and the server need not explicitly reply to the KRB_AP_REQ. However, if mutual authentication is being performed, the KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is required in response. If a sequence number is to be included, it should be randomly chosen. A subkey should be included in the message. [The method adapted for generating subkey is..TBD].The KRB_AP_REP message is encrypted in the session key extracted from the ticket. If the application server selects any of the cipher suites proposed by client, it sends out a AP Reply message. AP Reply has the following format, aprepmsg ::= SEQUENCE { doi, /* Domain of interpretation */ KRB5_AP_REP, /* ASN.1 DER encoded KRB5_AP_REP structure */ Application specific Data, /* To be defined for SIP Security -TBD */ Selected Cipher Suite, Re establish Flag, ACK Required Flag, Sha1hmac Hash /* SHA1 HMAC over all the above fields */ } 4.2.5 Wakeup Message: This message is sent by SIP Server to trigger a kerberos negotiation from SIP UA. This message will have following format wakeupmsg ::= SEQUENCE { DOI, /* Domain of interpretation */ nonce, Application Principal Name } Expires may 2003 [Page 7] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 4.2.6 Kerb Error Message: This message is sent by KDC or application server,it will hold the following format kerberror ::= SEQUENCE { DOI, /* Domain of interpretation */ KRB5_ERROR /* ASN.1 DER encoded KRB5_ERROR structure */ } 4.3 Kerberos Credentials: A ticket plus the secret session key necessary to successfully use that ticket in an authentication exchange, constitutes kerberos credentials. These credentials are time bound values, bound by life time of the ticket, after expiry of the credenitals SIP UA may renew the tickets from KDC or may discard the existing credentials. Although the derived keys may be continued to be used by the application, but for renegotiating with the application server, SIP UA needs to obtain Kerberos credentials through AS Exchange with KDC. A Ticket contains the following information: Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno[0] INTEGER, realm[1] Realm, sname[2] PrincipalName, enc-part[3] EncryptedData } Encrypted part of ticket, EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags[0] TicketFlags, key[1] EncryptionKey, crealm[2] Realm, cname[3] PrincipalName, authtime[5] KerberosTime, starttime[6] KerberosTime OPTIONAL, endtime[7] KerberosTime, renew-till[8] KerberosTime OPTIONAL, } 5. SIP security This sub-section provides an overview of SIP payload format and the message exchange along with the contents of each message. 5.1 SIP Payload format Once the client is authenticated, and key is generated. SIP client can use the given key for encrypting, authenticating or encrypting & authenticating its payload. The SIP message after the encryption/authentication will look like as given. Expires may 2003 [Page 3] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 =================================================== | IP header | Transport hdr| | =================================================== ------------------------------------------------------ |SIP Headers | SIP Headers authenticated/encrypted |Modified by |(include AUTH |Proxies |header) + |in clear txt|authenticated/encrypted Msg payload(SDP) ------------------------------------------------------ Figure-4 The SIP headers, which are modified by the interim proxies are kept in clear text and other SIP headers (which are processed by end devices ) are either authenticated and/or encrypted based on the cipher_suite agreed upon during key generation procedure (refer to figure-3) The authentication header is a new header(TBD whether to reuse existing header) defined along with other SIP headers, which will carry 16 bytes of HMAC-SHA1 signature and 4 bytes of nonce(TBD...) When end-to-end SIP packets are authenticated, the authentication header (16 bytes long) contains HMAC-SHA1 signature, which is generated using the subkey (as given in Figure-2) for the headers which are used/processed by the end-clients. This way the integrity of the packet contents (i.e SIP payload) is maintained and protected against the man-in-middle attack.The nonce (random value) is always set to new value for every message to avoid replay attacks. Expires may 2003 [Page 8] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 When end-to-end SIP packet are encrypted, the authentication header will not be included in the message. The SIP headers(processed by end-devices) and message contents (i.e. SDP) will be encrypted using encryption algorithm specified in cipher_suite, which is agreed upon during key generation procedure (refer to figure-3) (TO BE DISCUSSED: What will happen if intermi proxy is state-ful and not state-less..) 5.2 SIP Payload with Authentication Header: Following figure depicts SIP packet with authetntication header. -------------------------------------------------- --- | SIP Headers added/modified by proxies | In Clear text |--------------------------------------------------|--- |---------------- | | Auth Header | SIP Headers | |---------------- | | | |--------------------------------------------------| Auth/encrypted. | | | | | | | Message Body | | | | | | | -------------------------------------------------- --- Auth Header ---------------------------------- | 16 byte hmac-sha1 hash | Nonce | ---------------------------------- Figure 5 5.3 SIP Message exchanges and contents The SIP messages are exchanged between end clients are either encrypted or authenticated based on the cipher_suite agreed upon by both the clients during key generation procedure (refer to figure-3) The following figure-5 shows the different message exchange for a SIP session with interim proxies (stateless or statefull??). Expires may 2003 [Page 9] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 SIP Terminal(SIP_T) SIP Server(SIP_SRV | with KDC) | AS REQUEST(K1) | |------------------------------------------------------------->| | AS Reply (K2) | |<-------------------------------------------------------------| | AP Request (K3) | |------------------------------------------------------------->| | AP Reply (K4) | |<-------------------------------------------------------------| | | | | | loc1.mot.com(proxy) loc2.mot.com(proxy) | | | | | | Invite (F1) | Invite (F2) | Invite (F3) | |--------------->|--------------------->|--------------------->| | 100 Trying(F4) | 100 Trying (F5) | 100 Trying (F6) | |<---------------|<---------------------|<---------------------| | | | 180 Ringing (F7) | | | 180 Ringing (F8) |<---------------------| | 180 Ringing(F9)|<---------------------| | |<---------------| | 200 OK (F10) | | | 200 OK (F11) |<---------------------| | 200 OK (F12) |<---------------------| | |<---------------| | | | | ACK (F13) | | |------------------------------------------------------------->| Note: The arrows are depicting the sequence but not the timing for these messages. The message contents for each of the above message is given in the following figures. F1 INVITE SIP_T -> loc1.mot.com proxy ======================================= INVITE sip:Manoj@loc2.mot.com SIP/2.0 Via: SIP/2.0/UDP pc1.loc1.mot.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Manoj } Added for proxy, if packet is encrypted From: Rohit } Added for proxy, if packet is encrypted Call-Id: a84b4c76e66710 } Added for proxy, if packet is encrypted Auth_hdr:"ABCDEFGHIJKLNMOP","12323444" To: UFMI * From: Rohit ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (SDP Not Shown) Expires may 2003 [Page 10] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 F2 INVITE loc1.mot.com proxy -> loc2.mot.com proxy ==================================================á INVITE sip:Manoj@loc2.com SIP/2.0 Via: SIP/2.0/UDP bigsite.loc1.mot.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc1.loc1.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 (??) Max-Forwards: 69 To: Manoj } Added for proxy, if packet is encrypted From: Rohit } Added for proxy, if packet is encrypted Call-Id: a84b4c76e66710 } Added for proxy, if packet is encrypted Auth_hdr:"ABCDEFGHIJKLNMOP","12323444" To: Manoj * From: Rohit ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (SDP Not Shown) F3 INVITE loc2.mot.com proxy -> UFMI ===================================== INVITE sip:Manoj@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.loc2.mot.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigsite.loc1.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.loc1.mot.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Manoj } Added for proxy, if packet is encrypted From: Rohit } Added for proxy, if packet is encrypted Call-Id: a84b4c76e66710 } Added for proxy, if packet is encrypted Auth_hdr:"ABCDEFGHIJKLNMOP","12323444" To: Manoj * From: Rohit ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142 (SDP Not Shown) F4 100 Trying loc1.mot.com proxy -> SIP_T =========================================== á SIP/2.0 100 Trying Via: SIP/2.0/UDP pc1.loc1.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: Manoj From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Expires may 2003 [Page 11] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 F5 100 Trying Iden.com proxy -> miel.mot.com proxy á =================================================== SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.miel.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: UFMI From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 F6 180 Ringing UFMI --> Iden.com proxy ====================================== SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.Iden.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.miel.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 F7 180 Ringing Iden.com proxy-->miel.mot.com proxy ================================================== á SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.miel.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 F8 180 Ringing miel.mot.com proxy-->SIP_T ========================================= á SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Content-Length: 0 Expires may 2003 [Page 12] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 F9 200 OK UFMI-->Iden.com proxy ===============================á SIP/2.0 200 OK Via: SIP/2.0/UDP server10.Iden.com;branch=z9hG4bK4b43c2ff8.1;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.miel.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 á (UFMIÆs SDP not shown) F10 200 OK Iden.com proxy-->miel.mot.com proxy ============================================== SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.miel.mot.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 (UFMIÆs SDP not shown) F11 200 OK miel.mot.com proxy-->SIP_T ===================================== á SIP/2.0 200 OK Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds8;received=192.0.2.1 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131 á (UFMIÆs SDP not shown) F12 ACK SIP_T-->UFMI ===================== á ACK sip:UFMI@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc1.miel.mot.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: UFMI ;tag=a6c85cf From: SIP_T ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 Expires may 2003 [Page 13] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 References [1]: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, october 1994. [2]: draft-ietf-cat-kerberos-pk-init-16.txt: Public Key Cryptography for Initial Authentication in Kerberos [3]: RFC 3261- SIP: Session Initiation Protocol [4]: RFC 1510- The Kerberos Network Authentication Service (V5) [5]: PKCS #7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note Version 1.5 Revised November 1, 1993 [6]: R. Housley. Cryptographic Message Syntax. draft-ietf-smime-cms-13.txt, April 1999, approved for publication as RFC. [7]: R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key Infrastructure, Certificate and CRL Profile, January 1999. Request for Comments 2459 Acknowledgements Authors' Addresses Manoj Wagle Motorola India Electronics Ltd. The Senate, No 33A Ulsoor Road, Bangalore, Karnataka, India-560042 Fax: +91-80-5598660 Phone: +91-80-5598615 (x4006) EMail: A12651@motorola.com Rohit Aradhaya Motorola India Electronics Ltd. The Senate, No 33A Ulsoor Road, Bangalore, Karnataka, India-560042 Fax: +91-80-5598660 Phone: +91-80-5598615 (x4005) EMail: A15094@motorola.com Expires may 2003 [Page 14] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires may 2003 [Page 15] INTERNET-DRAFT Out-of-Band authentication for SIP november 2002