[VOIPSEC] SIP B2BUA and Digest Authentication using

[Simon Horne]

At 02:43 PM 6/11/2005, Christopher A. Martin wrote:
>*<You wrote>
> >> Simon Horne* s.horne at packetizer.com 
> <mailto:Voipsec%40voipsa.org?Subject=%5BVOIPSEC%5D%20SIP%20B2BUA%20and%20Digest%20Authentication%20using&In-Reply-To=436D468E.6070001%40InfraVAST.com>
>/>> Sun Nov 6 01:35:47 GMT 2005/
>
>>>As you are aware Chris, the H.323 secure softphone we are developing 
>>>does something similar to this (example in next beta release).
>
>Actually my focus to date has been SIP, I have yet to work with H.323 
>except with respect to replacing it, so I was not aware of this, but this 
>is exciting from
>a practical live example of it being done for VoIP.
>Question, for your product, has this introduced any of the items that 
>people in the past have claimed would be a detriment? e.g, PKI would slow 
>things down too much for people to accept the delays caused by it during 
>call setup...

No not all, even to me this was initially surprising. Their is virtually no 
noticeable delay in call setup (under 1 sec). The implementation from the 
start was designed and effort put in to avoid delays. All key management is 
handled multi threaded and quite separate from call processing. The TLSv1 
negotiation is compressed into 2 messages, 1 in each direction and the 
encryption engine uses assembler routines.to speed up 
ciphering/deciphering. Also since the session encryption key (using 
diffie-hellman) is negotiated prior to the caller answering, there is no 
2-3 sec delay at the start of the call.

Not saying we didn't have problems. The main issue was application startup. 
Initially, it would take several seconds for the PKI and Crypto Engine to 
load. So we had to do some thread management to reduce the startup time.

The application has it's own internal PKI which can be replaced by an 
operator supplied external password encrypted PKCS#12 file.


>>>The provider can issue the client with a PKCS#12 password encrypted file 
>>>(via email) which contains a X.509 Cert, Private key and CA Chain. These 
>>>are loaded into the softphone at startup. The softphone will 
>>>automatically authenticate the X.509 cert against its loaded CA Chain 
>>>and once authenticated will use the DN (distinguished Name) of the X.509 
>>>as its username (or user id) to attempt to gain admission to the 
>>>specified gatekeeper using MD5 or HMAC-96 hash.
>>>The gatekeeper can then use Radius to authenticate the admission 
>>>request. (Many commercial GK's already support radius including the open 
>>>source gnugk project using freeradius)
>>>The great advantage of using X.509 is that you can insert a signed cert 
>>>(using EP1's private key) into EP1's call setup message carried 
>>>end-to-end to use as an authentication mechanism. If the CA that signed 
>>>EP1's cert is present in EP2's CA chain then the caller can be verified 
>>>and authenticated. EP2 can then decide it's own security policy and 
>>>reject the call if the cert is missing or invalid.
>>>Simon
>
>Thanks, this verifies that I am on the right track. Do you have any 
>whitepapers on
>your implementation that you can share regarding this?

We will once we are through the initial beta testing phase and I have a bit 
more time .:(

Simon


Simon Horne
Director
Packetizer Labs
www.packetizer.com/labs