1 / 19

Rserpool Security Trust Argument draft-ietf-rserpool-asap-13.txt

Rserpool Security Trust Argument draft-ietf-rserpool-asap-13.txt. Maureen Stillman November 6, 2006 maureen.stillman@nokia.com. Current Status. Generate updates to security considerations sections for ASAP and ENRP. Threat Summary.

jemima
Download Presentation

Rserpool Security Trust Argument draft-ietf-rserpool-asap-13.txt

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rserpool SecurityTrust Argument draft-ietf-rserpool-asap-13.txt Maureen Stillman November 6, 2006 maureen.stillman@nokia.com

  2. Current Status • Generate updates to security considerations sections for ASAP and ENRP

  3. Threat Summary • PE registration/deregistration flooding and/or spoofing (threat 2.1, 2.2, 2.3, 2.4) • Security mechanism in response: ENRP server authenticates the PE PE ENRP Registration messages

  4. Threat Summary • PE registers with a malicious ENRP server (threat 2.6) • Security mechanism in response: PE authenticates the ENRP server ENRP PE Mutual authentication

  5. Threat Summary • Malicious ENRP server joins the pool • Mitigation: mutual authentication of ENRP servers ENRP ENRP Mutual authentication

  6. Threat Summary • PU communicates with a malicious ENRP server for name resolution (Threat 2.7, 2.12) • Security mechanism in response: The PU authenticates the ENRP server. PU ENRP ENRP authentication

  7. Threat Summary • Replay attack (threat 2.8) • Can corrupt the ENRP database • Mitigation: security mechanism that supports protection from replay attack

  8. Threat Summary • Threat 2.10) Corrupted data which causes a PU to have misinformation concerning a name resolution • Security mechanism in response: Security protocol which supports integrity protection • Threat 2.11) Eavesdropper snooping on namespace information • Security mechanism in response: Security protocol which supports data confidentiality

  9. Summary of Requirements • Security mechanisms must provide support for authentication, integrity, data confidentiality and protection from replay attacks • TLS supports all this and we selected that for our security mechanism • No need to invent new security mechanisms

  10. Summary by component • PU (rserpool client) • Mandatory to implement • Authentication of ENRP server protects the client from malicious ENRP server • Confidentiality, integrity and protection from replay attacks

  11. Summary by component • PE • Mandatory to implement • Authentication of ENRP server protects it from malicious ENRP server • Confidentiality, integrity and protection from replay attacks

  12. Summary by component • ENRP • Mandatory to implement • Mutual authentication of ENRP server protects it from malicious ENRP server • Authentication of PE protects it from malicious PE • Confidentiality, integrity and protection from replay attacks

  13. Rserpool Security Architecture using TLS = easy trust argument PU PU Authentication of ENRP server, integrity, replay, confidentiality Mutual authentication, integrity, replay, confidentiality ENRP Server ENRP Server PE Mutual authentication, integrity, replay, confidentiality PE

  14. ENRP mixed security database PE A pool “foo” ENRP PE B pool “foo” PE C pool “foo” PE D pool “foo” ENRP foo Database PE A,C – secure PE B, D – not secure

  15. Proposed Solution Secure database PE A pool “foo” ENRP PE B pool “foo” Security error PE C pool “foo” Security error PE D pool “foo” ENRP foo Database PE A,C – secure

  16. Mixed data base issues • Need to mark PE registrations – some have used security to register others not • When a PU requests a list, does it get the mixed list or one or the other? • Makes implementation more complex • Consensus reached – mixed database not allowed; either all secure or all not secured

  17. Securing the control channel • Two options • Data channel only • Control and data -- We have decided to multiplex the data and control channel • When the data channel is secured, the control channel is as well due to the multiplex • If data is not secured, neither is the control • Consensus reached that this is adequate for securing the control channel

  18. TLS cipher suite • TLS has dozens of ciphersuites specified • Client and server perform a handshake to determine cipher suite • If they have no overlap; then communication is not possible • Usually specify a mandatory to implement ciphersuite to get around this problem • Consensus is TLS_RSA_WITH_AES_128_CBC_SHA mandatory; TLS_RSA_WITH_3DES_EDE_CBC_SHA recommended

  19. Next steps • Finish security update to ASAP and ENRP protocol

More Related