https://k5wiki.kerberos.org/w/api.php?action=feedcontributions&feedformat=atom&user=NpmccallumK5Wiki - User contributions [en]2026-05-12T19:21:23ZUser contributionsMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5434Projects/NAPTR2015-02-24T15:32:09Z<p>Npmccallum: /* Definitions */</p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><pre><br />
_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</pre></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</pre></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</pre></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</pre></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</pre></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# URI record prefix name<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first four, I propose:<br />
<br />
# _mskkdcp<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5433Projects/NAPTR2015-02-24T15:31:41Z<p>Npmccallum: /* Definitions */</p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><pre><br />
_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</pre></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</pre></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</pre></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</pre></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</pre></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# URI record prefix name<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first four, I propose:<br />
<br />
# _mskkdcp<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this thought.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5432Projects/NAPTR2015-02-24T01:38:50Z<p>Npmccallum: /* Definitions */</p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><pre><br />
_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</pre></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</pre></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</pre></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</pre></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</pre></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first three, I propose:<br />
<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this thought.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5431Projects/NAPTR2015-02-24T01:29:18Z<p>Npmccallum: /* The URI Record */</p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><pre><br />
_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</pre></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</pre></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</pre></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</pre></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</pre></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first three, I propose:<br />
<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# UDP or TCP at the client's discretion<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this thought.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5430Projects/NAPTR2015-02-24T01:28:49Z<p>Npmccallum: </p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><nowiki><br />
_ms_kkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</nowiki></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</pre></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><pre><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</pre></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</pre></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><pre><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</pre></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first three, I propose:<br />
<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# UDP or TCP at the client's discretion<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this thought.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5429Projects/NAPTR2015-02-24T01:22:32Z<p>Npmccallum: </p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><nowiki><br />
_ms_kkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</nowiki></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).<br />
<br />
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:<br />
<br />
<code><nowiki><br />
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.<br />
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.<br />
</nowiki></code><br />
<br />
<br />
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.<br />
<br />
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:<br />
<br />
<code><nowiki><br />
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .<br />
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.<br />
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.<br />
</nowiki></code><br />
<br />
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:<br />
<code><nowiki><br />
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.<br />
</nowiki></code><br />
<br />
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:<br />
<code><nowiki><br />
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.<br />
</nowiki></code><br />
<br />
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.<br />
<br />
= Definitions =<br />
<br />
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:<br />
<br />
# Service name<br />
# Protocol names<br />
# The behavior of a service without a protocol<br />
# The behavior of the "P" flag (optional)<br />
<br />
For the first three, I propose:<br />
<br />
# KRB5<br />
# UDP, TCP and MSKKDCP<br />
# UDP or TCP at the client's discretion<br />
<br />
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this thought.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/NAPTR&diff=5428Projects/NAPTR2015-02-23T23:33:04Z<p>Npmccallum: New page: = Background = The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the...</p>
<hr />
<div>= Background =<br />
<br />
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.<br />
<br />
= The URI Record =<br />
<br />
This is basically an equivalent for SRV records but for URIs. An example might be:<br />
<br />
<code><nowiki><br />
_ms_kkdcp IN URI 10 1 "https://kdc.example.com/kdc"<br />
</nowiki></code><br />
<br />
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.<br />
<br />
= The NAPTR Record =<br />
<br />
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string, which in this case will be the principal (including the realm), and a domain (which is only the realm).<br />
<br />
(More to come...)</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5419Projects/PAKE Preauthentication2014-10-31T19:42:07Z<p>Npmccallum: </p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
PAKE preauthentication also has benefits when not using a second factor. Namely, both sides are authenticated and no time synchronization is required.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Choose a client-supported PAKEProfile.<br />
# Choose a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Choose which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash: h<sub>2finfo</sub> = H(2FInfo).<br />
# Construct the first PAKEProfile-specific PAKEMessage using the principal's secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo: h<sub>2finfo</sub> = H(2FInfo).<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>, h<sub>2finfo</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>, h<sub>2finfo</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
With some 2FA methods, additional roundtrips may be required. In this case, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Security Considerations = <br />
Presuming that the underlying PAKE is secure, the shared key should be secure and no details about the first factor should be available to an active or passive attacker.<br />
<br />
We do not provide any sort of integrity for the PAKESupport message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation. The client and KDC should disable any weak PAKEProfile.<br />
<br />
Because the hash of 2FInfo appears in the key confirmation, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
* No downgrade attack is possible on the KDC's:<br />
** etype choice<br />
** 2FA requirement<br />
** 2FA methods<br />
* If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Timing attacks are a clear concern. The KDC needs to ensure that the same amount of time is spent no matter which factor fails to validate.<br />
<br />
Similarly, if subsequent 2FA roundtrips are required, they should be initiated only after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== FIDO Alliance - U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5418Projects/PAKE Preauthentication2014-10-31T19:18:23Z<p>Npmccallum: </p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
PAKE preauthentication also has benefits when not using a second factor. Namely, both sides are authenticated and no time synchronization is required.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== Implementation Considerations ==<br />
=== Client Roundtrips ===<br />
The MIT Kerberos client will likely require some core modification to handle the number of roundtrips required by this protocol.<br />
<br />
=== KDC State ===<br />
The KDC is generally stateless. Some mechanism will be needed to carry state across the roundtrips. Using PA-FX-COOKIE is probably the simplist. However, this will also likely break forward secrecy. Careful thought will be required for the implementation.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client. We do not provide any sort of integrety on this message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Decide upon a client-supported PAKEProfile.<br />
# Decide upon a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Decide which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash: h<sub>2finfo</sub> = H(2FInfo).<br />
# Construct the first PAKEProfile-specific PAKEMessage using the principal's secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo: h<sub>2finfo</sub> = H(2FInfo).<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>, h<sub>2finfo</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>, h<sub>2finfo</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
Because the hash of 2FInfo appears in the key confirmation, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
# No downgrade attack is possible for the requirement of a 2FA.<br />
# No downgrade attack is possible for the 2FA methods.<br />
# If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Special care should be taken by the KDC to avoid timing attacks if a second factor is present so as not to reveal to the client whether the first or second factor has failed. The second factor will often take several orders of magnitude more time than the first factor to validate.<br />
<br />
With some 2FA methods, additional roundtrips may be required. It is strongly recommended that subsequent roundtrips only be initiated after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
If subsequent roundtrips are required for 2FA, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
As noted above, the 2F should already be verified. <br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== FIDO Alliance - U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5417Projects/PAKE Preauthentication2014-10-31T17:42:55Z<p>Npmccallum: /* Rationale */</p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
PAKE preauthentication also has benefits when not using a second factor. Namely, both sides are authenticated and no time synchronization is required.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== Implementation Considerations ==<br />
=== Client Roundtrips ===<br />
The MIT Kerberos client will likely require some core modification to handle the number of roundtrips required by this protocol.<br />
<br />
=== KDC State ===<br />
The KDC is generally stateless. Some mechanism will be needed to carry state across the roundtrips. Using PA-FX-COOKIE is probably the simplist. However, this will also likely break forward secrecy. Careful thought will be required for the implementation.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client. We do not provide any sort of integrety on this message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Decide upon a client-supported PAKEProfile.<br />
# Decide upon a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Decide which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash.<br />
# Select a secret key and derive it using the previously created 2FInfo hash.<br />
# Construct the first PAKEProfile-specific PAKEMessage using the derived secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Because the secret is derived using a hash of the contents of 2FInfo, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
# No downgrade attack is possible for the etype.<br />
# No downgrade attack is possible for the requirement of a 2FA.<br />
# No downgrade attack is possible for the 2FA methods.<br />
# If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo.<br />
# Derives the password using the above hash.<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
Special care should be taken by the KDC to avoid timing attacks if a second factor is present so as not to reveal to the client whether the first or second factor has failed. The second factor will often take several orders of magnitude more time than the first factor to validate.<br />
<br />
With some 2FA methods, additional roundtrips may be required. It is strongly recommended that subsequent roundtrips only be initiated after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
If subsequent roundtrips are required for 2FA, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
As noted above, the 2F should already be verified. <br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== FIDO Alliance - U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5415Projects/PAKE Preauthentication2014-10-31T17:41:42Z<p>Npmccallum: Projects/PAKE 2FA moved to Projects/PAKE Preauthentication</p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== Implementation Considerations ==<br />
=== Client Roundtrips ===<br />
The MIT Kerberos client will likely require some core modification to handle the number of roundtrips required by this protocol.<br />
<br />
=== KDC State ===<br />
The KDC is generally stateless. Some mechanism will be needed to carry state across the roundtrips. Using PA-FX-COOKIE is probably the simplist. However, this will also likely break forward secrecy. Careful thought will be required for the implementation.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client. We do not provide any sort of integrety on this message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Decide upon a client-supported PAKEProfile.<br />
# Decide upon a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Decide which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash.<br />
# Select a secret key and derive it using the previously created 2FInfo hash.<br />
# Construct the first PAKEProfile-specific PAKEMessage using the derived secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Because the secret is derived using a hash of the contents of 2FInfo, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
# No downgrade attack is possible for the etype.<br />
# No downgrade attack is possible for the requirement of a 2FA.<br />
# No downgrade attack is possible for the 2FA methods.<br />
# If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo.<br />
# Derives the password using the above hash.<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
Special care should be taken by the KDC to avoid timing attacks if a second factor is present so as not to reveal to the client whether the first or second factor has failed. The second factor will often take several orders of magnitude more time than the first factor to validate.<br />
<br />
With some 2FA methods, additional roundtrips may be required. It is strongly recommended that subsequent roundtrips only be initiated after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
If subsequent roundtrips are required for 2FA, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
As noted above, the 2F should already be verified. <br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== FIDO Alliance - U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_2FA&diff=5416Projects/PAKE 2FA2014-10-31T17:41:42Z<p>Npmccallum: Projects/PAKE 2FA moved to Projects/PAKE Preauthentication</p>
<hr />
<div>#REDIRECT [[Projects/PAKE Preauthentication]]</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5414Projects/PAKE Preauthentication2014-10-31T17:40:25Z<p>Npmccallum: </p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== Implementation Considerations ==<br />
=== Client Roundtrips ===<br />
The MIT Kerberos client will likely require some core modification to handle the number of roundtrips required by this protocol.<br />
<br />
=== KDC State ===<br />
The KDC is generally stateless. Some mechanism will be needed to carry state across the roundtrips. Using PA-FX-COOKIE is probably the simplist. However, this will also likely break forward secrecy. Careful thought will be required for the implementation.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client. We do not provide any sort of integrety on this message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Decide upon a client-supported PAKEProfile.<br />
# Decide upon a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Decide which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash.<br />
# Select a secret key and derive it using the previously created 2FInfo hash.<br />
# Construct the first PAKEProfile-specific PAKEMessage using the derived secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Because the secret is derived using a hash of the contents of 2FInfo, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
# No downgrade attack is possible for the etype.<br />
# No downgrade attack is possible for the requirement of a 2FA.<br />
# No downgrade attack is possible for the 2FA methods.<br />
# If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo.<br />
# Derives the password using the above hash.<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
Special care should be taken by the KDC to avoid timing attacks if a second factor is present so as not to reveal to the client whether the first or second factor has failed. The second factor will often take several orders of magnitude more time than the first factor to validate.<br />
<br />
With some 2FA methods, additional roundtrips may be required. It is strongly recommended that subsequent roundtrips only be initiated after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
If subsequent roundtrips are required for 2FA, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
As noted above, the 2F should already be verified. <br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== FIDO Alliance - U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/PAKE_Preauthentication&diff=5413Projects/PAKE Preauthentication2014-10-31T17:33:45Z<p>Npmccallum: New page: = Rationale = Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over ...</p>
<hr />
<div>= Rationale =<br />
<br />
Multi-factor authentication is a highly desired feature. This lead first to the creation of an OTP preauthentication mechanism (RFC 6560). This mechanism sends the OTP over the wire, but encrypted inside of FAST.<br />
<br />
While this works, it is somewhat less than optimal. FAST can be difficult for clients to configure. This lead to some initial thoughts regarding the question of OTP Deployability ([[Projects/Improve OTP deployability]]).<br />
<br />
The best idea to come out of this discussion was to use the first factor to complete a PAKE exchange and then use the exchanged key to encrypt the second factor. So long as only a single round-trip is used to complete the second factor validation, it is possible to evaluate the first and second factors simultaneously. Even when such may not be possible, account locking policy (or some other mechanism) can be used to prevent online dictionary attacks.<br />
<br />
= Protocol Overview =<br />
<br />
This preauthentication mechanism differs a bit from establish mechanisms in that it takes an arbitrary number of roundtrips to complete. This varies based upon the PAKE algorithm and the second factor used (if any). At a minimum, two roundtrips are necessary. This is made possible by using KDC_ERR_MORE_PREAUTH_DATA_REQUIRED.<br />
<br />
== First Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
In the first roundtrip, the client MUST include PA-PAKE padata of PAKESupport. This indicates to the KDC which PAKE methods are supported by the client. We do not provide any sort of integrety on this message and as such a downgrade attack is possible. This behaves similarly to the etype negotiation.<br />
<br />
=== Response (KrbError) ===<br />
Upon receiving the AS-REQ message, the KDC will:<br />
# Decide upon a client-supported PAKEProfile.<br />
# Decide upon a client-supported etype with good security properties for the selected PAKEProfile.<br />
# Decide which second factors are configured, required and/or need to present challenges.<br />
# Generate the 2FInfo data structure, encode and hash it using the PAKEProfile specified hash.<br />
# Select a secret key and derive it using the previously created 2FInfo hash.<br />
# Construct the first PAKEProfile-specific PAKEMessage using the derived secret key.<br />
# Construct the PAKEStart padata and return it to the client (KDC_ERR_PREAUTH_REQUIRED).<br />
<br />
Because the secret is derived using a hash of the contents of 2FInfo, several important properties arise. If an active attacker tampers with the contents of 2FInfo, the key exchange will fail to verify. This guarantees:<br />
# No downgrade attack is possible for the etype.<br />
# No downgrade attack is possible for the requirement of a 2FA.<br />
# No downgrade attack is possible for the 2FA methods.<br />
# If a 2FA method provides a challenge, it has integrety protection.<br />
<br />
Upon receipt of the KrbError, the client:<br />
# Prompts for the password and any second factor information required.<br />
# Salts the password using ETYPE-INFO2-ENTRY.<br />
# Hashes the encoded contents of 2FInfo.<br />
# Derives the password using the above hash.<br />
<br />
== Intermediate PAKE Roundtrips (Optional) ==<br />
Depending on the PAKEProfile chosen, additional roundtrips may be required to complete the key exchange. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKEMessage. The number of intermediate roundtrips here is PAKEProfile specific and may be zero or more. However, the PAKE algorithm in any given PAKEProfile MUST be symmetric.<br />
<br />
== Last PAKE Roundtrip ==<br />
=== Request (AS-REQ) ===<br />
After any intermediate PAKE roundtrips are completed, the client is on the last step of the (symmetric) PAKE. The client should have, at this point:<br />
* The KDC's public key.<br />
* The 2FA response (optional).<br />
<br />
The client then:<br />
# Calculates the shared key (K).<br />
# Derives two new keys from the shared key (K): K<sub>kconf</sub>, K<sub>2fa</sub>.<br />
# Generates the key confirmation (PAKEProfile) hash: H(K<sub>kconf</sub>).<br />
# Encrypts any 2FA-specific response: E(K<sub>2fa</sub>, 2fa).<br />
# Generates PAKEFinish with the last PAKE-specific message, the key confirmation and the 2fa message (optional).<br />
# Sends AS-REQ with PA-PAKE as PAKEFinish.<br />
<br />
=== Response (AS-REP or KrbError) ===<br />
At this point the KDC, in most cases, will have everything it needs to complete verification. It uses the final PAKEMessage in PAKEFinish to calculate the shared key (K). This will be the same as the client's K if and only if the password, salt and 2FInfo hash are the same. The KDC now:<br />
# Derives three new keys from K: K<sub>kconf</sub>, K<sub>2fa</sub>, K<sub>tgt</sub>.<br />
# Verifies key confirmation: kconf == H(K<sub>kconf</sub>).<br />
# Decrypts and verifies the second factor (if present): verify(D(K<sub>2fa</sub>, 2fa)).<br />
# If all factors validate, the TGT is sent in an AS-REP encrypted with K<sub>tgt</sub>.<br />
<br />
Special care should be taken by the KDC to avoid timing attacks if a second factor is present so as not to reveal to the client whether the first or second factor has failed. The second factor will often take several orders of magnitude more time than the first factor to validate.<br />
<br />
With some 2FA methods, additional roundtrips may be required. It is strongly recommended that subsequent roundtrips only be initiated after the 2FA has already been verified. A failure to do this opens up the system to an independant online dictionary attack on the first factor. However, if this is not possible, this may be mitigated by an account locking policy. But again, this can be simply avoided by validating the 2F without subsequent roundtrips.<br />
<br />
If subsequent roundtrips are required for 2FA, the KDC MUST return KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) with PA-PAKE of PAKESecondFactor.<br />
<br />
== Subsequent 2F Roundtrips (Optional) ==<br />
<br />
Subsequent roundtrips may be required for 2FA. This includes subsequent AS-REQs and KrbError(KDC_ERR_MORE_PREAUTH_DATA_REQUIRED) responses. These contain PA-PAKE padata of PAKESecondFactor. <br />
<br />
An example of a subsequent 2F roundtrip is OTP synchronization after the first code has already been verified.<br />
<br />
As noted above, the 2F should already be verified. <br />
<br />
The conclusion of all subsequent 2F rountrips MUST be either an AS-REP or a final KrbError. <br />
<br />
= Proposed PAKEs =<br />
A brief note is necessary about elliptic curve cryptogrpahy (ECC). The standard integer Diffie-Hellman is rapidly becoming cumbersome. ECC provides an answer for this. PAKEProfile is flexible enough to support non-ECC based PAKEs, but at this time we are only focusing on implementing ECC PAKEs.<br />
<br />
== JPAKE ==<br />
[http://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling JPAKE] is a PAKE algorithm with a formal security proof. It is compatible with ECC without fancy tricks. It is broadly implemented (including OpenSSL, NSS and BouncyCastle). There are no known patents covering it. The only major downside of using it is that it requires two roundtrips.<br />
<br />
= Proposed 2FA Methods =<br />
Given that 2FA methods are expandable in this protocol, it is preferred that each type of 2FA create its own method. This will void having to create a 2FA method "to rule them all" and failing.<br />
<br />
== OATH (HOTP, TOTP, OCRA) ==<br />
HOTP (RFC 4226) and TOTP (RFC 6238) make great options for this protocol. A (very) simple example implementation is provided. OCRA (RFC 6287) support would be ideal as well; but more research is needed for this.<br />
<br />
== U2F ==<br />
[https://fidoalliance.org/specifications/download U2F] is the new cryptographic hardware challenge/response based on USB / Bluetooth HID. It is a clever design and provides great usability. More research is needed.<br />
<br />
= Implementation Details =<br />
== Client Roundtrips ==<br />
The MIT Kerberos client will likely require some core modification to handle the number of roundtrips required by this protocol.<br />
<br />
== KDC State ==<br />
The KDC is generally stateless. Some mechanism will be needed to carry state across the roundtrips. Using PA-FX-COOKIE is probably the simplist. However, this will also likely break forward secrecy. Careful thought will be required for the implementation.<br />
<br />
= Proposed ASN.1 =<br />
<br />
<code><br />
<pre><br />
KerberosPAKE DEFINITIONS EXPLICIT TAGS ::= BEGIN<br />
<br />
IMPORTS<br />
EncryptedData, Int32<br />
FROM KerberosV5Spec2 {<br />
iso(1) identified-organization(3)<br />
dod(6) internet(1) security(5) kerberosV5(2)<br />
modules(4) krb5spec2(2)<br />
}; -- as defined in RFC 4120.<br />
<br />
--<br />
--- Preauthentication Data<br />
--<br />
PA-PAKE ::= 150<br />
<br />
PAKEPreauthenticationData ::= CHOICE {<br />
PAKESupport,<br />
PAKEStart,<br />
PAKEMessage,<br />
PAKEFinish,<br />
PAKESecondFactor<br />
}<br />
<br />
--<br />
--- Key Exchange<br />
--<br />
PAKEProfile ::= ENUMERATED {<br />
jpake-p256-schnorr-sha256 (0)<br />
jpake-p521-schnorr-sha256 (1)<br />
}<br />
<br />
PAKESupport ::= [APPLICATION 1] SEQUENCE OF PAKEProfile<br />
<br />
PAKEStart ::= [APPLICATION 2] SEQUENCE {<br />
message [0] PAKEMessage,<br />
2fa [1] 2FInfo<br />
}<br />
<br />
PAKEMessage ::= [APPLICATION 3] SEQUENCE {<br />
profile [0] PAKEProfile,<br />
message [1] OCTET STRING<br />
}<br />
<br />
PAKEFinish ::= [APPLICATION 4] SEQUENCE {<br />
message [0] PAKEMessage,<br />
keyconf [1] OCTET STRING,<br />
2fa [2] PAKESecondFactor OPTIONAL<br />
}<br />
<br />
PAKESecondFactor ::= [APPLICATION 5] SEQUENCE {<br />
type [0] 2FType,<br />
message [1] EncryptedData<br />
}<br />
<br />
--<br />
--- Second Factor<br />
--<br />
2FType ::= ENUMERATED {<br />
oath (0)<br />
}<br />
<br />
2FSupport ::= SEQUENCE {<br />
type [0] PAKE2FType,<br />
challenge [1] OCTET STRING OPTIONAL -- Encoded, type-specific<br />
}<br />
<br />
2FInfo ::= SEQUENCE {<br />
etype [0] Int32, -- The etype used to encrypt the 2F<br />
required [1] BOOLEAN, -- If required is TRUE, there MUST be one supported 2F<br />
supported [2] SEQUENCE OF 2FSupport OPTIONAL<br />
}<br />
<br />
--<br />
--- JPAKE<br />
--<br />
SchnorrVerifiedKey ::= SEQUENCE {<br />
key [0] BIT STRING,<br />
gx [1] BIT STRING,<br />
r [2] BIT STRING<br />
}<br />
<br />
JPAKEFirstPass ::= [CONTEXT 1] SEQUENCE {<br />
x [1] SchnorrVerifiedKey,<br />
y [1] SchnorrVerifiedKey<br />
}<br />
<br />
JPAKESecondPass ::= [CONTEXT 2] SchnorrVerifiedKey<br />
<br />
-- A note on how OATH works:<br />
-- * No challenge is sent.<br />
-- * The first 2FMessage is 2FOATHCode<br />
-- * If synchronization is required, the second 2FMessage is 2FOATHSync<br />
-- * The reply is the next 2FOATHCode<br />
2FOATHCode ::= IA5String<br />
2FOATHSync ::= BOOLEAN (TRUE)<br />
</pre><br />
</code></div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5143Projects/OTPOverRADIUS2013-06-17T18:56:26Z<p>Npmccallum: /* kdc.conf */</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== krb5.conf or kdc.conf ===<br />
The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || N/A (RoUS mode) or '''secret''' MUST be specified! || /path/to/secret.file<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
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.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5136Projects/OTPOverRADIUS2013-06-07T20:11:55Z<p>Npmccallum: /* kdc.conf */</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || N/A (RoUS mode) or '''secret''' MUST be specified! || /path/to/secret.file<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
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.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5094Projects/OTPOverRADIUS2013-03-07T20:29:32Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
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.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5044Projects/OTPOverRADIUS2013-01-10T20:20:12Z<p>Npmccallum: /* Default Token Type */</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5043Projects/OTPOverRADIUS2013-01-10T20:19:58Z<p>Npmccallum: Undo revision 5025 by Npmccallum (Talk)</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
server = $KDCDIR/DEFAULT.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5042Projects/OTPOverRADIUS2013-01-10T20:19:38Z<p>Npmccallum: Undo revision 5026 by Npmccallum (Talk)</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
flags = <string><br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Flag Name || Meaning<br />
|-<br />
| downcase_realm || Convert the realm to lowercase ||<br />
|-<br />
| strip_realm || Discard the '@' symbol and everything that follows it ||<br />
|}<br />
<br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.flags || strip_realm || Comma separated list of flags ||<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
flags = downcase_realm<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5026Projects/OTPOverRADIUS2013-01-02T19:59:50Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
flags = <string><br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Flag Name || Meaning<br />
|-<br />
| downcase_realm || Convert the realm to lowercase ||<br />
|-<br />
| strip_realm || Discard the '@' symbol and everything that follows it ||<br />
|}<br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.flags || strip_realm || Comma separated list of flags ||<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
flags = downcase_realm<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5025Projects/OTPOverRADIUS2013-01-02T19:59:27Z<p>Npmccallum: Convert strip_realm to flags</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
flags = <string><br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Flag Name || Meaning<br />
|-<br />
| downcase_realm || Convert the realm to lowercase ||<br />
|-<br />
| strip_realm || Discard the '@' symbol and everything that follows it ||<br />
|}<br />
<br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.flags || strip_realm || Comma separated list of flags ||<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
flags = downcase_realm<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5024Projects/OTPOverRADIUS2013-01-02T19:24:53Z<p>Npmccallum: Remove custom attributes</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
server = $KDCDIR/DEFAULT.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (gethostname())<br />
* Service-Type (Authenticate-Only)<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5023Projects/OTPOverRADIUS2013-01-02T19:05:04Z<p>Npmccallum: Update to add the reserved DEFAULT token type configuration name</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
attribute = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|-<br />
| otp.<name>.attribute || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
There is a reserved token type name: '''DEFAULT'''. If no '''DEFAULT''' token type configuration is defined, the following configuration will be used internally:<br />
<code><br />
[otp]<br />
DEFAULT = {<br />
server = $KDCDIR/DEFAULT.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
You can override this default token type configuration by defining your own token type configuration with the name of '''DEFAULT'''.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5013Projects/OTPOverRADIUS2012-12-19T18:50:20Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
retries = <integer><br />
strip_realm = <boolean><br />
attribute = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.retries || 3 || Integer<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|-<br />
| otp.<name>.attribute || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
Internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5012Projects/OTPOverRADIUS2012-12-19T18:23:45Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
timeout = <integer><br />
strip_realm = <boolean><br />
attribute = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Default Value || Format<br />
|-<br />
| otp.<name>.server || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.timeout || 5 || Integer (seconds)<br />
|-<br />
| otp.<name>.strip_realm || true || Boolean<br />
|-<br />
| otp.<name>.attribute || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
Internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal, realm stripped per config; overridden by '''username''')<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5011Projects/OTPOverRADIUS2012-12-19T18:17:04Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.server || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || true || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
Internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5009Projects/OTPOverRADIUS2012-12-18T19:24:58Z<p>Npmccallum: strip_realm defaults to true, except for the internal default token type</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.server || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || true || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
strip_realm = false<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5008Projects/OTPOverRADIUS2012-12-18T19:23:26Z<p>Npmccallum: Remove all optional fields from the challenge/configuration</p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
server = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.server || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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).<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time<br />
== OTP Preauth Challenge Optional Fields ==<br />
According to RFC 6560, there are many optional fields. We currently do not have any plan to fill these in.</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5007Projects/OTPOverRADIUS2012-12-15T03:23:38Z<p>Npmccallum: </p>
<hr />
<div>{{project-target|1.12}}<br />
{{project-review|2012-12-21}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algorithm = <string><br />
server = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algorithm || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
'''NOTE:''' We only permit a single server to be defined because we are assuming that redundancy will be handled via DNS round-robin.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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 Access-Accept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=5000Projects/OTPOverRADIUS2012-12-11T18:45:38Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algorithm = <string><br />
server = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algorithm || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''server''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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 Access-Accept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4999Projects/OTPOverRADIUS2012-12-11T18:41:23Z<p>Npmccallum: /* FIPS compliance */</p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algorithm = <string><br />
remote = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algorithm || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''remote''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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 Access-Accept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
We are not targeting FIPS compliance, but for those who are interested here is the related information:<br />
* RADIUS is not FIPS compliant due to the use of MD5 in the protocol<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4998Projects/OTPOverRADIUS2012-12-11T18:01:17Z<p>Npmccallum: /* Proposal */</p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algorithm = <string><br />
remote = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algorithm || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''remote''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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 Access-Accept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4997Projects/OTPOverRADIUS2012-12-11T17:53:27Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algorithm = <string><br />
remote = <string><br />
secret = <string><br />
strip_realm = <boolean><br />
attributes = <name_or_number>:<value><br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algorithm || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.strip_realm || no || false || Boolean<br />
|-<br />
| otp.<name>.attribute || no || none || <name>:<value> or <number>:<value><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''remote''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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 Access-Accept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4992Projects/OTPOverRADIUS2012-12-05T21:59:17Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''remote''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
= Remaining Issues =<br />
== FIPS compliance ==<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4991Projects/OTPOverRADIUS2012-12-05T21:54:57Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
<br />
All values are optional except '''secret''' when a non-RoUS '''remote''' is specified.<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4990Projects/OTPOverRADIUS2012-12-05T21:53:55Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
<br />
=== Default Token Type ===<br />
If no valid token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
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.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4989Projects/OTPOverRADIUS2012-12-05T21:52:09Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" (RoUS mode) or '''secret''' MUST be specified! || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4988Projects/OTPOverRADIUS2012-12-05T21:51:00Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/<name>.socket || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR ERROR!* || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
* - If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, '''secret''' MUST be specified or the token type will be skipped as invalid.<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4987Projects/OTPOverRADIUS2012-12-05T21:48:58Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR ERROR!** || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
{|<br />
|*<br />
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.<br />
|-<br />
|**<br />
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, '''secret''' MUST be specified or the token type will be skipped as invalid.<br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4986Projects/OTPOverRADIUS2012-12-05T21:45:05Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR localhost:getservbyname("radius", "udp")** || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
{|<br />
|*<br />
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.<br />
|-<br />
|**<br />
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, something like localhost:1812.<br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
==== FIPS compliance ====<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4985Projects/OTPOverRADIUS2012-12-05T21:44:32Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR localhost:getservbyname("radius", "udp")** || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
{|<br />
|*<br />
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.<br />
|-<br />
|**<br />
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, something like localhost:1812.<br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* FIPS compliance:<br />
** RADIUS is not FIPS compliant due to MD5<br />
** EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
** Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4984Projects/OTPOverRADIUS2012-12-05T21:43:49Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR localhost:getservbyname("radius", "udp")** || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
{|<br />
|*<br />
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.<br />
|-<br />
|**<br />
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, something like localhost:1812.<br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== OTP Enablement ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* FIPS compliance<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4983Projects/OTPOverRADIUS2012-12-05T21:42:46Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
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.<br />
<br />
== Token Type Configuration ==<br />
=== kdc.conf ===<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
stripRealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
{| class="wikitable" style="width: 100%"<br />
! Name || Sent to Client || Default Value || Format<br />
|-<br />
| otp.<name>.vendor || yes || not sent || UTF8 String<br />
|-<br />
| otp.<name>.length || yes || not sent || Integer<br />
|-<br />
| otp.<name>.format || yes || not sent || Enumeration: decimal, hexadecimal, alphanumeric, binary or base64<br />
|-<br />
| otp.<name>.algID || yes || not sent || UTF8 URI<br />
|-<br />
| otp.<name>.server.remote || no || $KDCDIR/otp.socket OR $KDCDIR/<name>.socket* || host, host:port or /path/to/unix.socket<br />
|-<br />
| otp.<name>.server.secret || no || "" OR localhost:getservbyname("radius", "udp")** || String<br />
|-<br />
| otp.<name>.server.stripRealm || no || false || Boolean<br />
|-<br />
| otp.<name>.server.attributes || no || no additional attributes sent || <attrName> = <attrValue><br />
|}<br />
{|<br />
|*<br />
|If no token types are defined, we'll use a generic name. Otherwise, we use the name of the token type.<br />
|-<br />
|**<br />
|If '''remote''' indicates RoUS mode, an empty string is default. Otherwise, something like localhost:1812.<br />
|}<br />
<br />
=== Default Token Type ===<br />
If no token types are defined in the configuration, internally '''otp''' will define a default token type like this:<br />
<code><br />
[otp]<br />
<NO NAME> = {<br />
server = {<br />
remote = $KDCDIR/otp.socket<br />
}<br />
}<br />
</code><br />
<br />
However, if one or more token types are defined in the configuration, the first valid configuration defined will be considered the default token type.<br />
<br />
== Token Instance Configuration ==<br />
<br />
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:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
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.<br />
<br />
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.<br />
<br />
== Flag ==<br />
The '''REQUIRES_HW_AUTH''' flag will indicate whether or not the '''otp''' plugin is enabled for a principal.<br />
<br />
== Workflow ==<br />
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.<br />
<br />
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.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by the '''attributes''' section of the config except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* FIPS compliance<br />
* RADIUS is not FIPS compliant due to MD5<br />
* EAP might make RADIUS FIPS compliant and Fedora ships a libeap<br />
* Integration of EAP is not planned at this time</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4982Projects/OTPOverRADIUS2012-12-04T23:11:29Z<p>Npmccallum: /* Workflow */</p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called '''otp'''.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User String ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string '''otp''' with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If '''type''' is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user string.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string/configuration. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4981Projects/OTPOverRADIUS2012-12-04T23:10:29Z<p>Npmccallum: /* User Strings */</p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called '''otp'''.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User String ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string '''otp''' with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If '''type''' is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user string.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4980Projects/OTPOverRADIUS2012-12-04T23:10:23Z<p>Npmccallum: /* Workflow */</p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called '''otp'''.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User Strings ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string '''otp''' with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If '''type''' is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user string.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4979Projects/OTPOverRADIUS2012-12-04T23:09:10Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called '''otp'''.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User Strings ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string '''otp''' with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If '''type''' is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user strings.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4978Projects/OTPOverRADIUS2012-12-04T23:08:39Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called otp.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User Strings ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string ''otp'' with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If ''type'' is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user strings.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallumhttps://k5wiki.kerberos.org/wiki?title=Projects/OTPOverRADIUS&diff=4977Projects/OTPOverRADIUS2012-12-04T23:07:51Z<p>Npmccallum: </p>
<hr />
<div>{{project-early}}<br />
<br />
= Description =<br />
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 ([https://fedorahosted.org/AuthHub AuthHub]), based upon a plugin model. But our experimenting with this approach has demonstrated:<br />
# Access to vendor SDKs is non-trivial<br />
# All vendors provide a RADIUS server for OTP validation<br />
<br />
= Proposal =<br />
<br />
The KDC-side support for OTP should read configuration and forward token validation to an appropriate RADIUS server. This plugin will be called otp.<br />
<br />
=== Configuration ===<br />
<br />
Configuration should go into kdc.conf as it may contain secrets that shouldn't be world readable. The configuration is defined as follows:<br />
<code><br />
[otp]<br />
<name> = {<br />
vendor = <string><br />
length = <integer><br />
format = <enum: decimal|hexadecimal|alphanumeric|binary|base64><br />
algID = <string><br />
server = {<br />
remote = <string><br />
secret = <string><br />
striprealm = <boolean><br />
attributes = {<br />
<name> = <string><br />
}<br />
}<br />
}<br />
</code><br />
<br />
The follow values are informational only and will be sent to the client only if set in the config.<br />
* vendor<br />
* length<br />
* format<br />
* algID<br />
<br />
Server configuration is a little more complicated. If no token types are defined in the configuration and a user is configured for OTP access (see below), the otp plugin will fall back to a non-standard RADIUS-over-UNIX-Socket (RoUS; inconceivable!): $KDCDIR/otp.socket. If at least one token type is defined, any token type that does not implement the server section will fall back to RoUS, but with the name of the tokenType: $KDCDIR/<name>.socket.<br />
<br />
If a server section is defined, it MUST contain the secret field or the token type will be ignored. This is to prevent insecure message passing in non-RoUS mode. All of the other values are optional, with the following defaults:<br />
* remote: localhost:getservbyname("radius", "udp")<br />
* striprealm: false<br />
* attributes: none<br />
<br />
The remote field can contain the following formats:<br />
* host<br />
* host:port<br />
* /path/to/unix/socket<br />
<br />
=== User Strings ===<br />
<br />
Some portion of the otp plugin configuration is user specific. This value will be stored as the user string ``otp`` with the following (JSON) format:<br />
<code><br />
[{<br />
"type": <string>,<br />
"id": <string>,<br />
"username": <string><br />
}, ...]<br />
</code><br />
<br />
All values above are optional. If ``type`` is not specified, the following will occur:<br />
* If no token types are defined in the config, we fall back to RoUS mode with the default socket.<br />
* If one or more token type is specified, the first one with valid configuration will be chosen.<br />
<br />
=== Workflow ===<br />
In the first pass (no PA-OTP-REQUEST present), a PA-OTP-CHALLENGE will be generated from the configuration and user strings.<br />
<br />
Upon receipt of a PA-OTP-REQUEST, the KDC will attempt to match the PA-OTP-REQUEST with a tokenInfo from the user string. All matching tokenInfo objects will then be used as configuration for RADIUS validation, in the order they were specified, stopping after the first AccessAccept response is received.<br />
<br />
=== RADIUS Packet ===<br />
The packet sent to the configured RADIUS server will contain:<br />
* User-Name (default: user principal; realm stripped per config)<br />
* User-Password (otp-value from PA-OTP-REQUEST)<br />
* NAS-Identifier (default: gethostname())<br />
* Service-Type (default: Authenticate-Only)<br />
* Any custom attributes defined<br />
<br />
Any of the attributes specified above may be overridden by custom attribute except User-Name and User-Password.<br />
<br />
=== Remaining Issues ===<br />
* Should we use a RADIUS library or hand-craft packets? We should use a RADIUS library which provides support for EAP methods. Unfortunately no such libraries exist.<br />
* This architecture is not FIPS compliant due to RADIUS' use of MD5</div>Npmccallum