1 / 11

Rserpool Security

Rserpool Security. Maureen Stillman March 17, 2003 maureen.stillman@nokia.com. Design Team objectives. Revisit i-d draft-ietf-rserpool-threats-00.txt Add directives from Transport Area Directors Secure Rserpool infrastructure does not include application (PU-PE data)

evelynharris
Download Presentation

Rserpool Security

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 Security Maureen Stillman March 17, 2003 maureen.stillman@nokia.com

  2. Design Team objectives • Revisit i-d draft-ietf-rserpool-threats-00.txt • Add directives from Transport Area Directors • Secure Rserpool infrastructure • does not include application (PU-PE data) • Support client (PU) to ENRP server authentication • PU authenticates ENRP server to prevent rogue ENRP servers

  3. PE and ENRP security • Mandatory to implement TLS OR IPsec security • Choice is design decision left to the designers and network architects • Using IPsec • Must implement draft-ietf-ipsec-sctp-04 • Using TLS • MUST support TLS with SCTP as described in RFC 3436 or TLS over TCP as described in RFC 2246

  4. PU Authenticates ENRP server • Consensus reached by the security design team • TLS would be used by the PU to authenticate the ENRP server (mandatory to implement) • Other methods of authentication are optional • TLS was deemed mandatory to implement for reasons of interoperability

  5. Open Issue • Even if the PU “trusts” the ENRP server, ENRP might have gotten registrations from rougue PEs • Do we need to require that the PEs be authenticated to the ENRP server as well?

  6. Threats to consider • What are the threats? • Rouge ENRP servers • Rouge registrations from PEs or unauthorized PEs • PE thinks it has registered with a “good” ENRP server, but it is really a rouge • Corrupted data • Sent from the ENRP server to the PU • Sent from the PE to the ENRP server • PU-PE authentication addresses only #1

  7. Issues • What I really want to know is that the addresses served up to the PU are “trusted” • Want to know that all the PEs have registered with a “trusted” ENRP server • Therefore, the real threat is the one of bogus addresses for PEs or no addresses for the PEs • Do we need data integrity as well? (yes)

  8. Security Architecture PU PU authentication, integrity authentication, integrity Mutual authentication, integrity ENRP Server PE PE Mutual authentication, integrity

  9. The big question • Do we need to make mandatory implementation of the previous architecture? • If we don’t when PU queries the ENRP server and authenticates, it doesn’t necessarily mean anything about the data it gets

  10. Still not done – control channel • Need to define the control channel • Need to secure the control channel as it is part of the Rserpool infrastructure

  11. Next steps • Design team should keep meeting • When the control channel definition is complete, we will need to define the security for it • Are we there yet? • Are there other open issues? • Join the security design team to help • E-mail maureen.stillman@nokia.com

More Related