Eron, I understand your point in case of proxy-proxy communication. with respect to client certificate validation I have following opinion.
Certificate verification by the server involves following steps: 1. server issues "Certificate Request" which is optional. 2. Client will present its certificate through "Client Certificate" message. This will contain full chain of certificate till highest CA. 3. Server will now check if the certifying authority certificate is trusted. 4. If the CA authority is trusted, it validates till the lowest certificate (client's certificate). This validation process involves whether certificate of lower level entity is signed by its immidiate top level. 5. For the lowest level certificate (belonging to the entity), the server checks if it really owns the private key. I think this process is sufficient for ensuring that certificate of the other party is authorized. If above steps fail, server can abort connection at this stage itself. 6. Next the client has to send "Certificate verify" message. The server can now check if the client _really owns_ the private key for the certificate he has presented. If the signature verification in step 6 above succeeds, then we can be 100% sure that the client is authorized. But if some entity has lost his private key to un-authorized people, there is no solution. It is case of compromized security by the entity himself. regards, Shetti "Eron Stein" <[EMAIL PROTECTED]> on 03/12/2003 12:44:38 PM To: Shrinivas Shetti/HSSBLR cc: [EMAIL PROTECTED] Subject: [Sip-implementors] Re: [Sipping] TLS and sip messages Hi, I understand why for a client comunicating with a server the server will garantee its idientity with TLS, while the client will have to respond to a challange. My question concerns two proxies. where each proxy want's to verify the other side by using TLS. As I understood it it is premissable to require client authentication for incoming connections (infact RFC3261/ 26.3.1 mandates that capability). I understand that certificate are associated to entities but I still think that the commonName filed and the altDns fileds still needs to be checked so the server that was presented with the certificate knows that the certificate was indeed issued to the presenting server (again RFC3261/ 26.3.1). >From: [EMAIL PROTECTED] >To: "Eron Stein" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: [Sipping] TLS and sip messages >Date: Wed, 12 Mar 2003 10:36:45 +0530 > > > >Hi Eron, > >For the server, TLS is more for the data transport security than client >authentication. > >Client authentication is done at application layer by challenging the user >(this happens if the SIP message didnt contain correct credentials). > >I think the certificates can-not be associated with an IP address. >certificates are assigned to an entity by a trusted CA. > >When we verify the certificate, we'll have to verify if the certificate >presented by the peer is signed by the trusted CA. It need not be >verified against any IP address. B'cause certificates are not assigned for >IP address but to some functional entities. > >regards, >Shetti > > > > > >"Eron Stein" <[EMAIL PROTECTED]> on 03/11/2003 06:37:32 PM > >To: [EMAIL PROTECTED], [EMAIL PROTECTED] >cc: (bcc: Shrinivas Shetti/HSSBLR) > >Subject: [Sipping] TLS and sip messages > > > > >Hi, >I want to implement sip over TLS and I have encountered a problematic >question: >The question concerns a situation where an incoming connection has to be >authenticated with TLS, that is TLS handshake with client certificates. >(That might be the situation between two proxies). > >As I understand it the side that initiated the connection has no problem >authenticating the certificate since it knows the connection's desired >destination, and can compare that destination address to the addresses >found >in the certificate. > >The problem is with the side that receives the connection (the server). >What >domain-name/ip should that proxy use to check if the certificate matches >the >connection address. > >One possibility is to check the certificate against the source address of >the incoming connection, that option might be problematic if the >certificate >contains a FQDN rather than a specific IP address. > >Another possibility is to wait for the first message on the connection and >compare the host field from the VIA header the the common name in the >certificate. > >I would appreciate any comments, ideas or real world implementation data on >the matter. > >Regards, >Eron Stein. > >_________________________________________________________________ >STOP MORE SPAM with the new MSN 8 and get 2 months FREE* >http://join.msn.com/?page=features/junkmail > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use [EMAIL PROTECTED] for questions on current sip >Use [EMAIL PROTECTED] for new developments of core SIP > > > > _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
