Subject: [Sip] RE: I-D ACTION:draft-dotson-sip-certificate-auth-sol-00.txt

From: "Rai, Anupam \(Anupam\)" <[email-masked]>
Date: Sun, 25 Feb 2007 23:25:40 -0700

(1) Some mechanism is required for transporting client certificate if
it's not possible to use identity-info as described in RFC 4474

A new header could be defined as follows
       Identity-Cert = "Identity-Cert" HCOLON ident-cert
       ident-cert = LDQUOT 32LHEX RDQUOT
       32LHEX = BASE64 encoded client certificate.

(2) Following scenario need to be supported (Using Example in Sec 8 to
elaborate) if permitted by Registrar's local policy
     
    Bob's hardphone UAC using certificate for authentication.
    Bob's softphone UAC using username/password for authentication.

With following restrictions
    - Both UAC using same AOR.
    - Bob's softphone UAC is not aware of this specification.

(3) An optional algorithm "rsa-enc" for producing challenge response as
follows

     - UAC sends the initial request with Identity-Cert OR Identity-Info
headers.
     - Registrar validates the certificate and verifies that the owner
of the certificate
       is authorized to submit the request.
     - Registrar then creates a unique password for this instance of the
client, encrypts
       the password using UAC's public key and sends that to client
along with other parameters
       in the WWW-Authenticate header.
     - UAC uses it's private key to extract the password from the
WWW-Authenticate header
     - UAC then uses this password to create the challenge-response.

This optional mechanism can be used by implementations to minimize the
number public key operations
at the expense of maintaining state for each authenticated UAC.
Server should delay creation of state until UAC has proven possession of
private key by sending the 
correct challenge response. Server can implement this by encrypting the
password with it's own public key 
or a symmetric key known only to server and sending that inside opaque
field of the WWW-Authenticate
header.

-Anupam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 07 February 2007 20:50
> To: [email-masked]
> Subject: I-D ACTION:draft-dotson-sip-certificate-auth-sol-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: SIP Certificate Authentication Solution
> 	Author(s)	: S. Dotson
> 	Filename	: draft-dotson-sip-certificate-auth-sol-00.txt
> 	Pages		: 20
> 	Date		: 2007-2-7
> 	
> 
>    This document specifies SIP Certificate Authentication (SCA), a
>    challenge-response mechanism that uses public key cryptography to
>    perform certificate-based authentication in Session Initiation
>    Protocol (SIP) based architectures.  Performing authentication in 
> SIP
>    with certificates will provide stronger authentication capabilities
>    and increase possible deployment scenarios in SIP networks.  The
>    scope is limited to the authentication of the SIP UA to the SIP
>    Service Provider's network.  It does not include UA to UA
>    authentication within its scope.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica
> te-auth-sol-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of

> the message.
> You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then "get 
> draft-dotson-sip-certificate-auth-sol-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE
> /internet-drafts/draft-dotson-sip-certificate-auth-sol-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 

------------------------------

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

End of Sip Digest, Vol 34, Issue 6
**********************************

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip