proposed voip security profile1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Proposed VoIP Security Profile1 PowerPoint Presentation
Download Presentation
Proposed VoIP Security Profile1

Loading in 2 Seconds...

play fullscreen
1 / 20
mabyn

Proposed VoIP Security Profile1 - PowerPoint PPT Presentation

57 Views
Download Presentation
Proposed VoIP Security Profile1
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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