Difference between revisions of "Projects/OTPOverRADIUS"
Npmccallum (talk | contribs) |
Npmccallum (talk | contribs) |
||
Line 52: | Line 52: | ||
=== Default Token Type === |
=== Default Token Type === |
||
− | If no token types are defined in the configuration, internally '''otp''' will define a default token type like this: |
+ | If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this: |
<code> |
<code> |
||
[otp] |
[otp] |
||
Line 62: | Line 62: | ||
</code> |
</code> |
||
− | However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type. |
+ | However, if one or more valid token types are defined in the configuration, the first valid configuration defined will be considered the default token type. |
== Token Instance Configuration == |
== Token Instance Configuration == |
Revision as of 17:53, 5 December 2012
Contents
Description
In 1.11 KRB5 gained client side support for OTP Preauth (RFC 6560), but up until now there is no server side support in tree. Red Hat has created an out-of-tree solution (AuthHub), based upon a plugin model. But our experimenting with this approach has demonstrated:
- Access to vendor SDKs is non-trivial
- All vendors provide a RADIUS server for OTP validation
Proposal
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called otp. In additional to standard RADIUS, the otp plugin will support a non-standard RADIUS over Unix Socket (RoUS; inconceivable!) mode for handling local companion daemons.
Token Type Configuration
kdc.conf
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:
[otp] <name> = { vendor = <string> length = <integer> format = <enum: decimal|hexadecimal|alphanumeric|binary|base64> algID = <string> server = { remote = <string> secret = <string> stripRealm = <boolean> attributes = { <name> = <string> } } }
Name | Sent to Client | Default Value | Format |
---|---|---|---|
otp.<name>.vendor | yes | not sent | UTF8 String |
otp.<name>.length | yes | not sent | Integer |
otp.<name>.format | yes | not sent | Enumeration: decimal, hexadecimal, alphanumeric, binary or base64 |
otp.<name>.algID | yes | not sent | UTF8 URI |
otp.<name>.server.remote | no | $KDCDIR/<name>.socket | host, host:port or /path/to/unix.socket |
otp.<name>.server.secret | no | "" (RoUS mode) or secret MUST be specified! | String |
otp.<name>.server.stripRealm | no | false | Boolean |
otp.<name>.server.attributes | no | no additional attributes sent | <attrName> = <attrValue> |
Default Token Type
If no valid token types are defined in the configuration, internally otp will define a default token type like this:
[otp] <NO NAME> = { server = { remote = $KDCDIR/otp.socket } }
However, if one or more valid token types are defined in the configuration, the first valid configuration defined will be considered the default token type.
Token Instance Configuration
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string otp with the following JSON formatted array of token objects:
[{ "type": <string>, "id": <string>, "username": <string> }, ...]
If type is not specified then it refers to the default token type as defined above. The id field identifies the unique id of the token and is sent in the PA-OTP-CHALLENGE. The username field overrides the default User-Name attribute sent in the RADIUS packet.
All values above are optional. If the user string is not set (i.e. NULL) or is an empty string or is an empty list, then a user string of "[{}]" will be assumed.
OTP Enablement
The REQUIRES_HW_AUTH flag will indicate whether or not the otp plugin is enabled for a principal.
Workflow
In the first pass (no PA-OTP-REQUEST present), the otp plugin will look up the REQUIRES_HW_AUTH flag on the given principal. If not set, no PA-OTP-CHALLENGE will be generated. Otherwise we will look up the otp user string and a PA-OTP-CHALLENGE will be generated and sent to the client.
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a token type using the otp user string and kdc.conf configuration. All matches will then be used as configuration for RADIUS validation, in the order they were specified in the otp user string, stopping after the first AccessAccept response is received.
RADIUS Packet
The packet sent to the configured RADIUS server will contain:
- User-Name (default: user principal; realm stripped per config)
- User-Password (otp-value from PA-OTP-REQUEST)
- NAS-Identifier (default: gethostname())
- Service-Type (default: Authenticate-Only)
- Any custom attributes defined
Any of the attributes specified above may be overridden by the attributes section of the config except User-Name and User-Password.
Remaining Issues
FIPS compliance
- RADIUS is not FIPS compliant due to MD5
- EAP might make RADIUS FIPS compliant and Fedora ships a libeap
- Integration of EAP is not planned at this time