logo_kerberos.gif

Difference between revisions of "Projects/OTPOverRADIUS"

From K5Wiki
Jump to: navigation, search
(Update to add the reserved DEFAULT token type configuration name)
Line 47: Line 47:
   
 
=== Default Token Type ===
 
=== Default Token Type ===
Internally '''otp''' will define a default token type like this:
 
  +
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:
 
<code>
 
<code>
 
[otp]
 
[otp]
<NO NAME> = {
+
DEFAULT = {
server = $KDCDIR/otp.socket
+
server = $KDCDIR/DEFAULT.socket
 
strip_realm = false
 
strip_realm = false
 
}
 
}
 
</code>
 
</code>
  +
  +
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.
   
 
== Token Instance Configuration ==
 
== Token Instance Configuration ==
Line 66: Line 68:
 
</code>
 
</code>
   
If '''type''' is not specified then it refers to the default token type as defined above. The '''username''' field overrides the default User-Name attribute sent in the RADIUS packet.
+
If '''type''' is not specified then it refers to the '''DEFAULT''' token type as defined above. 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.
 
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.

Revision as of 15:05, 2 January 2013

This project is targeted at release 1.12.

An announcement has been sent to krbdev@mit.edu starting a review of this project. That review will conclude on 2012-12-21.

Comments can be sent to krbdev@mit.edu.


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:

  1. Access to vendor SDKs is non-trivial
  2. 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 addition 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> = {
  server = <string>
  secret = <string>
  timeout = <integer>
  retries = <integer>
  strip_realm = <boolean>
  attribute = <name_or_number>:<value>
 }

Name Default Value Format
otp.<name>.server $KDCDIR/<name>.socket host, host:port or /path/to/unix.socket
otp.<name>.secret "" (RoUS mode) or secret MUST be specified! String
otp.<name>.timeout 5 Integer (seconds)
otp.<name>.retries 3 Integer
otp.<name>.strip_realm true Boolean
otp.<name>.attribute none <name>:<value> or <number>:<value>

All values are optional except secret when a non-RoUS server is specified.

NOTE: We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.

Default Token Type

There is a reserved token type name: DEFAULT. If no DEFAULT token type configuration is defined, the following configuration will be used internally:

[otp]
 DEFAULT = {
  server = $KDCDIR/DEFAULT.socket
  strip_realm = false
 }

You can override this default token type configuration by defining your own token type configuration with the name of DEFAULT.

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>,
   "username": <string>
 }, ...]

If type is not specified then it refers to the DEFAULT token type as defined above. 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 the flag is set, a generic PA-OTP-CHALLENGE will be sent to the client (no optional fields will be filled in).

Upon receipt of a PA-OTP-REQUEST, the KDC will look up the RADIUS servers using the otp user string and kdc.conf configuration. All RADIUS servers will be used for validation, in the order they were specified in the otp user string, stopping after the first Access-Accept response is received.

RADIUS Packet

The packet sent to the configured RADIUS server will contain:

  • User-Name (default: user principal, realm stripped per config; overridden by username)
  • 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

We are not targeting FIPS compliance, but for those who are interested here is the related information:

  • RADIUS is not FIPS compliant due to the use of MD5 in the protocol
  • EAP might make RADIUS FIPS compliant and Fedora ships a libeap
  • Integration of EAP is not planned at this time

OTP Preauth Challenge Optional Fields

According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.