Rserpool Security draft-ietf-rserpool-threats-02.txt

1
Rserpool Security draft-ietf-rserpool-threats-02.
txt

• Maureen Stillman
• March 3, 2004
• maureen.stillman_at_nokia.com

2
Current Status

• IESG Evaluation of draft-ietf-rserpool-threats-02.
  txt
• Received comments from IESG and updated document
  generated -03
• Good doc and covers the threats
• Add to security considerations a summary of
  security requirements derived from the threats
• Generate 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
PU
PU
Authentication of ENRP server, integrity, replay,
confidentiality
Mutual authentication, integrity, replay,
confidentiality
ENRP Server
PE
ENRP Server
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
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

16
TLS ports 1 port or 2 ports?2 port solution
IANA assigns two ports for ENRP
PE
ENRP
PE
Register with ENRP using TLS
17
TLS ports 1 port or 2 ports?1 port solution
IANA assigns one port only
PE
ENRP
PE
First send unsecured message with upgrade to TLS
request MITM can refuse upgrade Fix Protocol
change to ASAP to request upgrade cant be
rejected by ENRP
18
Ports received - success

• We received advice from Jon Peterson and Eric
  Rescorla
• Both endorse the 2 port and one port solutions
• We have asked IANA and received the following
  ports
• TCP 3863, 3864
• UDP 3863, 3864
• SCTP ????

19
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

20
Issue 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

21
Next steps

• Need to update ASAP and ENRP protocol text to
  include all security issues
• security considerations section or elsewhere in
  ASAP/ENRP
• Waiting for comments on updated i-d
• Next need to send threats-03 back for IESG review
  with updates included