Add support for RADIUS TLS-PSK #108
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the advent of Blast-RADIUS there have been strong moves towards using RADIUS over TLS, and increased vendor support. The traditional mutual certificate auth method is hard to configure, but RADIUS TLS-PSK is a promising alternative. It is already supported by both FreeRADIUS and radsecproxy.
To allow institutions to configure RADSEC TLS-PKS, DjNRO needs to be extended to accommodate a new RADIUS type and to configure a TLS PSK identity and a TLS PSK key. This PR provides for that.
There are some assumptions in the implementation:
TLS PSK will use RADIUS-TLS
In order to avoid extending the
protofield from 12 characters, I've opted to use an identifier ofradius-pskinRADPROTOS. This is technically ambiguous because there should be options forradius-tls-pskandradius-dtls-pskin RADPROTOS. However, DTLS doesn't seem widely implemented and is commented out in DjNRO's stock config. I think it's safe to assume this will be RADIUS-TLS rather than DTLS. Of failing that, that NROs will support one or the other.PSK identity for the local server
The local FLR server's PSK identity is not user-configurable. Instead, it is generated as a Network Access Identifier from the institution's UUID and a pre-defined realm configured in local_settings.py (new
NRO_TLSPSK_REALMsetting).This creates an opaque token in the user portion, as contemplated by 4.2 of draft-ietf-radext-tls-psk. An example identifier is:
The identity is exposed in the user interface, and in the servdata YAML. It can also be constructed from the database if needs be.
PSK for a remote server
The remote IdP's PSK identity can be configured and is simply validated as a Network Access Identifier.
Shared pre-shared key
In theory, the IdP and SP connections can be configured completely independently. This means that a pair of servers can have a different RADIUS secret and/or a different PSK key for each direction.
However, DjNRO already assumes that both directions will share a common RADIUS secret. This also seems to an assumption made by many server admins. To avoid having to add two separate fields for PSK keys, this implementation extends that assumption by assuming that both directions will share a common TLS pre-shared key.
This isn't strictly in accordance with draft-ietf-radext-tls-psk, but it's a reasonable compromise between an ideal implementation and practical constraints. It will probably also reduce confusion.
Our own implementation of this extends things by having the initial PSK key pre-generate as a strong random string, rather than relying on the admin to supply one.