Rserpool Security Trust Argument draft-ietf-rserpool-asap-13.txt Maureen Stillman November 6, 2006

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

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 ENRP PE Registration messages

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next steps Finish security update to ASAP and ENRP protocol