aboutsummaryrefslogtreecommitdiffstats
path: root/plt/.gitignore
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2011-09-29 09:08:31 +0200
committerAnders Svensson <[email protected]>2011-10-06 16:29:46 +0200
commitb138f9e6879e44732e681d368704345acdf26b1b (patch)
tree0b6751230dc6fab72fe4dee860faf760443a57f5 /plt/.gitignore
parentd01551f400e2a7944dcc10319be0c9f248ca3179 (diff)
downloadotp-b138f9e6879e44732e681d368704345acdf26b1b.tar.gz
otp-b138f9e6879e44732e681d368704345acdf26b1b.tar.bz2
otp-b138f9e6879e44732e681d368704345acdf26b1b.zip
Add tls support to capabilities exchange
To upgrade a connection to TLS or not, that is the question. It is possible for us to send a CER offering both NO_INBAND_SECURITY and TLS and for the peer to answer likewise: RFC 3588 doesn't make clear that a CEA should be unambiguous about the choice of security. Thus, if TLS is offered then assume the server is prepared to for a handshake. Similarly, when receiving a CER, choose TLS if it's offered and be unambiguous about our choice in CEA. There is no ssl:maybe_accept that would let us receive a handshake if it comes or another message if it doesn't. The choice of TLS should probably be made into a callback so that an application can decide based on the peer's Origin-Realm for example. Such a callback could also be used to reject a CER/CEA. Handle Inband-Security-Id values other than NO_INBAND_SECURITY and TLS by assuming that they require no intervention by the transport module, treating them like NO_INBAND_SECURITY. Whether or not this is reasonable (or useful) is unclear. There may be a need for more sychronization than we have on offer. (Having to do something before taking the connection up for example.) Note that diameter_peer_fsm must be upgraded before diameter_capx because of the new return value from diameter_capx:recv_CEA/2.
Diffstat (limited to 'plt/.gitignore')
0 files changed, 0 insertions, 0 deletions