logo_kerberos.gif

Difference between revisions of "Projects/OTPOverRADIUS"

From K5Wiki
Jump to: navigation, search
 
(31 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
{{project-early}}
 +
{{project-rel|1.12}}
   
 
= Description =
  
= Description =
Line 8: Line 8:
 
= Proposal =
  
= 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.
 +
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 ==
  
== Token Type Configuration ==
−
=== kdc.conf ===
 +
=== krb5.conf or 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:
 +
The configuration is defined as follows:
 
<code>
  
<code>
 
[otp]
  
[otp]
 
<name> = {
  
<name> = {
−
vendor = <string>
 +
server = <string>
−
length = <integer>
 +
secret = <string>
−
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64>
 +
timeout = <integer>
−
algID = <string>
 +
retries = <integer>
−
server = {
 +
strip_realm = <boolean>
−
remote = <string>
  
−
secret = <string>
  
−
stripRealm = <boolean>
  
−
attributes = {
  
−
<name> = <string>
  
−
}
  
−
}
  
 
}
  
}
 
</code>
  
</code>
   
 
{| class="wikitable" style="width: 100%"
  
{| class="wikitable" style="width: 100%"
−
! Name || Sent to Client || Default Value || Format
 +
! Name || Default Value || Format
 
|-
  
|-
−
| otp.<name>.vendor || yes || not sent || UTF8 String
 +
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket
 
|-
  
|-
−
| otp.<name>.length || yes || not sent || Integer
 +
| otp.<name>.secret || N/A (RoUS mode) or '''secret''' MUST be specified! || /path/to/secret.file
 
|-
  
|-
−
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64
  
  +
| otp.<name>.timeout || 5 || Integer (seconds)
 
|-
  
|-
−
| otp.<name>.algID || yes || not sent || UTF8 URI
 +
| otp.<name>.retries || 3 || Integer
 
|-
  
|-
−
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket
  
  ⚫
| otp.<name>.strip_realm || true || Boolean
−
|-
  
−
| otp.<name>.server.secret || no || "" OR localhost:getservbyname("radius", "udp")** || String
  
−
|-
  
⚫
| otp.<name>.server.stripRealm || no || false || Boolean
  
−
|-
  
−
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue>
  
−
|}
  
−
{|
  
−
|*
  
−
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.
  
−
|-
  
−
|**
  
−
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, something like localhost:1812.
  
 
|}
  
|}
  +
  +
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 ===
  
=== Default Token Type ===
−
If no token types are defined in the configuration, 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 = {
 +
strip_realm = false
−
remote = $KDCDIR/otp.socket
  
−
}
  
 
}
  
}
 
</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.
  
  +
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 68: Line 59:
 
[{
  
[{
 
"type": <string>,
  
"type": <string>,
−
"id": <string>,
  
 
"username": <string>
  
"username": <string>
 
}, ...]
  
}, ...]
 
</code>
  
</code>
   
−
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.
 +
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 an empty string or is an empty list, then a user string of "[{}]" will be assumed.
   
−
== Flag ==
 +
== OTP Enablement ==
−
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.
 +
The '''otp''' plugin will be enabled for all principals which have the '''otp''' user string set, regardless of its value. Conversely, if the '''otp''' user string is unset, the '''otp''' plugin will be disabled for the principal.
   
 
== Workflow ==
  
== 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.
 +
In the first pass (no PA-OTP-REQUEST present), the '''otp''' plugin will look up the '''otp''' user string on the given principal. If the string is set (i.e. non-NULL), 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 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.
 +
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 ===
  
=== RADIUS Packet ===
 
The packet sent to the configured RADIUS server will contain:
  
The packet sent to the configured RADIUS server will contain:
−
* User-Name (default: user principal; realm stripped per config)
 +
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')
 
* User-Password (otp-value from PA-OTP-REQUEST)
  
* User-Password (otp-value from PA-OTP-REQUEST)
−
* NAS-Identifier (default: gethostname())
 +
* NAS-Identifier (gethostname())
−
* Service-Type (default: Authenticate-Only)
 +
* Service-Type (Authenticate-Only)
−
* Any custom attributes defined
 +
  +
= 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.
  +
  +
= Testing =
  +
  +
libkrad will be tested with C test programs located in lib/krad. Some of the programs will spawn a Python daemon which uses pyrad to provide a simple RADIUS server to test against.
  +
  +
The OTP module will be tested by a new script tests/t_otp.py, which also uses pyrad to provide a RADIUS server to test against.
  +
  +
= Documentation =
  +
  +
A new page admin/otp.rst will describe KDC configuration for OTP.
  +
  +
= Mailing list discussions =
  +
  +
* http://mailman.mit.edu/pipermail/krbdev/2012-December/011300.html
  +
* http://mailman.mit.edu/pipermail/krbdev/2013-May/011528.html
  +
  +
= Commits =
  +
  +
8b8f031c6e64360a26c484b548d2158944e09087 Add libkrad
  +
4b5dd8bcfb10af254fb9efbe4cf39befe5b1e6ac Add server-side otp preauth plugin
  +
f6cb089daed2615d0b1594d7ccc20d617eb374eb Fix skip logic in t_otp.py
  +
acb490bd01235511294ecb6b23750e648e48f7dc Fix OTP KDC module get_string error handling
  +
  +
Completed in {{bug|7678}}.
  +
  +
= Release notes =
   
−
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.
  
  +
Administrator experience:
   
−
=== Remaining Issues ===
  
  +
* Add a FAST OTP preauthentication module for the KDC which uses RADIUS to validate OTP token values.
−
* 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
  

Latest revision as of 13:26, 11 October 2013

This project was completed in release 1.12.


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

krb5.conf or kdc.conf

The configuration is defined as follows: 

[otp]
 <name> = {
  server = <string>
  secret = <string>
  timeout = <integer>
  retries = <integer>
  strip_realm = <boolean>
 }

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

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 = {
  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 an empty string or is an empty list, then a user string of "[{}]" will be assumed.

OTP Enablement

The otp plugin will be enabled for all principals which have the otp user string set, regardless of its value. Conversely, if the otp user string is unset, the otp plugin will be disabled for the principal.

Workflow

In the first pass (no PA-OTP-REQUEST present), the otp plugin will look up the otp user string on the given principal. If the string is set (i.e. non-NULL), 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 (gethostname())
  • Service-Type (Authenticate-Only)

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.

Testing

libkrad will be tested with C test programs located in lib/krad. Some of the programs will spawn a Python daemon which uses pyrad to provide a simple RADIUS server to test against.

The OTP module will be tested by a new script tests/t_otp.py, which also uses pyrad to provide a RADIUS server to test against.

Documentation

A new page admin/otp.rst will describe KDC configuration for OTP.

Mailing list discussions

Commits

   8b8f031c6e64360a26c484b548d2158944e09087 Add libkrad
   4b5dd8bcfb10af254fb9efbe4cf39befe5b1e6ac Add server-side otp preauth plugin
   f6cb089daed2615d0b1594d7ccc20d617eb374eb Fix skip logic in t_otp.py
   acb490bd01235511294ecb6b23750e648e48f7dc Fix OTP KDC module get_string error handling

Completed in [krbdev.mit.edu #7678].

Release notes

Administrator experience:

  • Add a FAST OTP preauthentication module for the KDC which uses RADIUS to validate OTP token values.
Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&oldid=5227"