Proposed VoIP Security Profile1

1. Proposed VoIP Security Profile1 Senthil Sengodan Nokia Research Center, Boston

2. Profile Overview • Purpose • combats most attacks • easily deployable • good performance • Issues not yet addressed in profile • firewall traversal • specific algorithms & parameters not nailed down

3. Profile Overview

4. RAS Authentication • Three possible methods • Discovery messages not authenticated; subsequent messages use • symmetric key cryptography (secret) • public key cryptography (certificates) • D-H exchange during discovery; subsequent messages use derived secret • IPSEC

5. RAS Authentication • If discovery messages are not authenticated, attacks are possible • Flooding GK with spurious GRQs • attacker uses EP1’s alias in GRQ • uses own IP Src Addr to route GCF back to him • Attacker modifies genuine packets in transit • Changes Confirm to Reject • Modifies other fields in Confirm

6. RAS Authentication • Enable ICV for discovery messages • use password based with hashing (MD-5 or SHA-1) • can be used for unicast GRQ, GCF, GRJ • use with multicast GRQ needs investigation • Use crypto-token + ICV for subsequent RAS messages • password with hashing

7. How about D-H? • Provides perfect forward secrecy • not really needed when encryption is not done • Computationally very intensive • Authentication of D-H for multicast GRQ is not clear • Instead, we can make the key derived from the password strong

8. How about IPSEC? • Setting up an IPSEC security association (SA) for multicast GRQ is not clear • Overhead involved in setting up an IPSEC SA for GCF only may be large • Pace of deployment

9. Other RAS security services • Confidentiality & non-repudiation not provided in this profile • Confidentiality • not critical for RAS • need to use IPSEC or define usage in RAS • Non-repudiation • needs public key cryptography • Access control • Authentication + ACLs

10. RAS Profile • Authentication + Integrity • Enable ICV for discovery messages • use password based with hashing (MD-5 or SHA-1) • can be used for unicast GRQ, GCF, GRJ • use with multicast GRQ needs investigation • Use crypto-token + ICV for subsequent RAS messages • password with hashing (MD-5 or SHA-1)

11. H.225 Authentication • Without authentication, attacks are possible • sending Setup messages (with its own parameters) to tie up EP’s resources • spoofing an EP • modify genuine Setup packets in transit

12. H.225 Authentication • Three methods • use token/crypto-token fields in UUIE • use IPSEC • use TLS

13. Crypto-token • End-to-end secret? • Desirable if direct routed model is used • Not needed if GKs are trusted for H.225 in GK routed model • Cannot be established apriori • Profile recommends • GK-GK routed model • Using locally shared secret • password with hashing (MD-5 or SHA1)

14. What about TLS? • TLS requires either secret or public keys during connection securing • In direct routed model • end-to-end TLS connection is not easy • public key cryptography undesirable • end-to-end shared secret establishment not easy • With GK-GK routed • TLS overhead undesirable • can incorporate same functionality into crypto-token

15. What about IPSEC? • Security association establishment overhead may be undesirable • Deployment issues

16. Other H.225 security services • Confidentiality & non-repudiation not provided in this profile • Confidentiality • desirable if eavesdropper should not know which two parties tried to establish contact • Non-repudiation • desirable so that customer cannot claim later that he did not make the call

17. H.225 Profile • Provides authentication & integrity • Recommends the use of GK-GK routed model • Uses locally shared secret with hashing (MD-5 or SHA-1) in crypto-token of UUIE

18. H.245 • Issues are similar to H.225 • Recommendation is similar to H.225

19. Media Stream • Profile provides authentication, integrity and confidentiality • Follows H.235 recommendation for media stream encryption • Uses fast re-keying if low-strength algorithm is chosen

20. Conclusion