https://k5wiki.test.kerberos.org/w/api.php?action=feedcontributions&feedformat=atom&user=Nalin 2026-05-14T18:15:57Z User contributions MediaWiki 1.27.4 https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5322 2014-06-02T18:36:27Z

<p>Nalin: /* Implementation Design */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> * In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll default to using the system-wide default trust store and adding an `http_anchor' option to krb5.conf to allow the location to be overridden.<br /> ** The setting will be read from the realm-specific subsection of the `realms' section.<br /> ** As with PKINIT, we can be describe locations using `FILE:', `DIR:', or `ENV:' prefixes.<br /> <br /> * As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting.<br /> ** When examining names in a certificate, if a subjectAltName of the type being compared (either hostname or address) is not present, we'll attempt to compare the expected name with the value of a CN attribute in the certificate's subject name.<br /> ** If a name has three or more labels in it, the `*' wildcard will be accepted in the first label.<br /> ** The rest of the name will be compared by lower-casing all ASCII characters and then performing an exact comparison.<br /> <br /> ==Test Plan==<br /> <br /> The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy. Tests should include cases which succeed and cases in which the client rejects the server's certificate.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5293 2014-04-21T23:00:25Z

<p>Nalin: /* Test Plan */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> * In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf. These will function similarly to the similarly-named counterparts which were added for PKINIT:<br /> ** Each will be read first from the realm-specific subsection of the `realms' section. If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf. Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.<br /> ** As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.<br /> <br /> * As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting. Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.<br /> <br /> ==Test Plan==<br /> <br /> The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy. Tests should include cases which succeed and cases in which the client rejects the server's certificate.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5292 2014-04-21T22:26:12Z

<p>Nalin: /* Test Plan */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> * In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf. These will function similarly to the similarly-named counterparts which were added for PKINIT:<br /> ** Each will be read first from the realm-specific subsection of the `realms' section. If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf. Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.<br /> ** As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.<br /> <br /> * As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting. Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.<br /> <br /> ==Test Plan==<br /> <br /> The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to the test's KDC via the test's proxy.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5291 2014-04-21T21:47:21Z

<p>Nalin: /* Implementation Design */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> * In order to facilitate self-testing and make the procedure for configuring the set of CAs which a client will trust in production environments clearer, we'll be ignoring the system-wide default trust store and adding `http_anchor', `http_revoke', and `http_require_crl_checking' options to krb5.conf. These will function similarly to the similarly-named counterparts which were added for PKINIT:<br /> ** Each will be read first from the realm-specific subsection of the `realms' section. If no value for a setting is found, the library will look for a key of the same name in the `libdefaults' section of krb5.conf. Unlike with PKINIT, it will not be looking at a realm-specific subsection of `libdefaults'.<br /> ** As with PKINIT, both anchor and CRL information can be specified using `FILE:', `DIR:', or `ENV:' prefixes to describe locations.<br /> <br /> * As most HTTPS clients do, when the client library connects to an HTTPS proxy, it will need to check that the naming information in the certificate which the server presents to the client matches the client's notion of the name of the server to which it is connecting. Whether this requires an `http_hostname' option which works similarly to the `pkinit_kdc_hostname' option, when most HTTPS clients merely check for the name they extract from the URL they were given, is not yet determined.<br /> <br /> ==Test Plan==<br /> <br /> The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to test's KDC via the test's proxy.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5290 2014-04-21T21:33:42Z

<p>Nalin: /* Test Plan */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> The self-tests will be expanded to make use of a locally-installed copy of [https://pypi.python.org/pypi/kdcproxy kdcproxy] to start up a proxy server, and should issue all of AS, TGS, and kpasswd requests to test's KDC via the test's proxy.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5289 2014-04-21T21:30:15Z

<p>Nalin: /* Implementation Design */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related server location fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = https://&lt;proxy.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTPS cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator, an enumerated type called k5_transport. Because the contents of a proxy request also incorporate the realm's name and the `page' portion of the URL, we'll need to start to carry them around, too.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., by building against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5288 2014-04-21T21:25:58Z

<p>Nalin: /* Implementation Process */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Initial portions of the patch series will focus on refactoring the client library's internal send-to-kdc logic to make the addition of new transports (such as a possible HTTP transport to be added later) less disruptive going forward. The HTTPS transport implementation will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = (http|https)://&lt;kdc.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., build against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5287 2014-04-21T21:23:47Z

<p>Nalin: /* Overview */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server and relay back their response. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Some of the client library's internal send-to-kdc logic will be refactored to make adding new transports (such as a possible HTTP transport to be added later) less disruptive. The HTTPS transport will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = (http|https)://&lt;kdc.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., build against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5286 2014-04-21T21:21:27Z

<p>Nalin: /* Overview */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add an HTTPS transport which can be used to send Kerberos and kpasswd protocol requests to an HTTPS proxy which will then send the requests to a KDC or kpasswd server. This change is useful especially for firewall configurations that allow traffic on port 443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Some of the client library's internal send-to-kdc logic will be refactored to make adding new transports (such as a possible HTTP transport to be added later) less disruptive. The HTTPS transport will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = (http|https)://&lt;kdc.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., build against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5285 2014-04-21T21:19:15Z

<p>Nalin: /* Implementation Process */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add HTTP and HTTPS transport to Kerberos traffic. This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> An HTTPS transport will be implemented. Some of the client library's internal send-to-kdc logic will be refactored to make adding new transports (such as a possible HTTP transport to be added later) less disruptive. The HTTPS transport will follow Microsoft's specification. We will implement it using OpenSSL initially and may add optional support for building using NSS at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = (http|https)://&lt;kdc.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., build against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/HTTP_Transport&diff=5284 2014-04-21T21:11:43Z

<p>Nalin: /* Microsoft */</p> <hr /> <div>{{project-early}}<br /> {{project-target|1.13}}<br /> <br /> ==Overview==<br /> <br /> This project intends to add HTTP and HTTPS transport to Kerberos traffic. This change is useful especially for firewall configurations that allow traffic on port 80/443 but not on port 88.<br /> <br /> ==Precedent==<br /> <br /> Both Heimdal and Microsoft Kerberos have such a technology.<br /> <br /> ===Heimdal===<br /> <br /> Heimdal has such a mechanism [https://github.com/heimdal/heimdal/blob/master/lib/krb5/send_to_kdc.c#L504 as seen here]. It uses a GET request with a base64-encoded version of the UDP traffic. Leaving aside questions of idempotence and RESTfulness, Apache has a URL length for GET of about 4000 characters, and requests of this nature have been measured as close to that limit and may exceed it in practice. It uses a separate field in krb5.conf for specification of the http_proxy to be used. There is almost no evidence of this in use in active deployment.<br /> <br /> ===Microsoft===<br /> <br /> Microsoft has documented their mechanism, MS-KKDCP, [http://msdn.microsoft.com/en-us/library/hh553774.aspx here]. It uses POST requests which is much more in keeping with the HTTP specification than GET, and it also specifies HTTPS to be used in all cases, as Microsoft's implementation does not work over plain HTTP.<br /> <br /> ==Implementation Process==<br /> <br /> HTTPS transport will be implemented first, followed optionally by HTTP transport. We will implement HTTPS transport that corresponds to Microsoft's specification. We will implement OpenSSL support initially and optionally may add NSS support at a later date.<br /> <br /> ==Implementation Design==<br /> <br /> * We will expand the definition of the `kdc` field (and related fields including kpasswd_server and admin_server) in krb5.conf to take a URL (optionally including page) in order to allow HTTP or HTTPS transport. The new syntax will look like this:<br /> kdc = (http|https)://&lt;kdc.addr&gt;[:&lt;port&gt;][/&lt;page&gt;]<br /> Note that the syntax (and parser) does not change in the non-HTTP{,S} cases. In order to facilitate this change, we will need to stop carrying a socktype around in the code that is either SOCK_DGRAM or SOCK_STREAM, and instead carry around our own protocol designator.<br /> <br /> * We will need to build against a cryptography library, and to add options to the build system for such. We will include an option to disable HTTPS support (i.e., build against no cryptographic library).<br /> <br /> ==Test Plan==<br /> <br /> Due to the nature of the changes, it will be extremely difficult to write test cases for the new code. However, the code can be tested by standing up Microsoft's implementation and running against that.<br /> <br /> ==Review==<br /> <br /> This section documents the review of the project according to [[Project policy]].<br /> It is divided into multiple sections. First, approvals should be listed. To list an approval type<br /> :&lt;nowiki&gt;#~~~~&lt;/nowiki&gt;<br /> (hash mark followed by four tilde characters) on its own line.<br /> The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with &lt;nowiki&gt;{{project-block}}&lt;/nowiki&gt;.<br /> <br /> ===Approvals===<br /> <br /> ===Discussion===<br /> The first version had comments from [http://mailman.mit.edu/pipermail/krbdev/2013-August/011698.html mail from ghudson], which we attempted to address.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5163 2013-07-18T13:29:53Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, and any PIN-related warnings, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;PKCS12:/path/to/blah&quot;: 0, &quot;FILE:/path/to/cert,/path/to/key&quot;: 0, &quot;PKCS11:module=opensc-pkcs11.so:slotid=1:token=My Card&quot;: 4}<br /> Suggested sample answer:<br /> {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}<br /> <br /> The challenge is an object whose keys are identity names, with their associated values being numbers corresponding to token flags. These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> * Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting answers (''krb5_responder_pkinit_set_answer'') will also be added.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> * We'll need to opportunistically test with at least one software PKCS#11 module, if found.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5082 2013-02-22T22:00:43Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;], 'token-flags':{}}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> <br /> The ''token-flags'' object a subset of the members of ''identities'' as keys, and numbers corresponding to token flags as their values. These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> * Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting answers (''krb5_responder_pkinit_set_answer'') will also be added.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> * We'll need to opportunistically test with at least one software PKCS#11 module, if found.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5078 2013-02-17T01:57:10Z

<p>Nalin: /* Testing */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;], 'token-flags':{}}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> <br /> The ''token-flags'' object a subset of the members of ''identities'' as keys, and numbers corresponding to token flags as their values. These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> * Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting at most one answer (''krb5_responder_pkinit_set_answer'') will also be added.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> * We'll need to opportunistically test with at least one software PKCS#11 module, if found.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5077 2013-02-17T01:50:30Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;], 'token-flags':{}}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> <br /> The ''token-flags'' object a subset of the members of ''identities'' as keys, and numbers corresponding to token flags as their values. These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> * Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting at most one answer (''krb5_responder_pkinit_set_answer'') will also be added.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5064 2013-02-05T18:31:33Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?<br /> {&quot;identities&quot;: [&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;], &quot;warnings&quot;: {&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;: &quot;PIN count low&quot;}}<br /> This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values. Another option is to just expose the &quot;flags&quot; value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:<br /> {&quot;identities&quot;: [&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;], &quot;token-flags&quot;: {&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;: 71036}}<br /> Another option is to expose selected flags as keys in an object which maps them to booleans:<br /> {&quot;identities&quot;: [&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;], &quot;token-flags&quot;: {&quot;PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1&quot;: {&quot;user-pin-locked&quot;: false, &quot;user-pin-count-low&quot;: false}}}<br /> '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like? '''YES'''; the API will look almost exactly like the krb5_responder_otp_XXX set of functions, but the type of the data structure which it returns will need to reflect what is exposed in the challange, and how it is exposed.<br /> <br /> '''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?<br /> ''The test script will attempt to load a soft token module using Python's ctypes module, and if found, it will configure and use that soft token. It could probably do this for more than one of the soft tokens that are out there, but that may have to be an ongoing effort.''<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5052 2013-01-24T23:22:21Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;warnings&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;PIN count low&quot;}}<br /> This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values. Another option is to just expose the &quot;flags&quot; value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;token-flags&quot;: {&quot;PKCS12:/path/to/blah&quot;: 76}}<br /> Another option is to expose selected flags as keys in an object which maps them to booleans:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;info&quot;: {&quot;PKCS12:/path/to/blah&quot;: {&quot;user-pin-locked&quot;: false, &quot;user-pin-count-low&quot;: false}}}<br /> '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like? '''YES'''; the API will look almost exactly like the krb5_responder_otp_XXX set of functions, but the type of the data structure which it returns will need to reflect what is exposed in the challange, and how it is exposed.<br /> <br /> '''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5051 2013-01-24T23:19:48Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;warnings&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;PIN count low&quot;}}<br /> This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values. Another option is to just expose the &quot;flags&quot; value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;token-flags&quot;: {&quot;PKCS12:/path/to/blah&quot;: 76}}<br /> Another option is to expose selected flags as keys in an object which maps them to booleans:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;info&quot;: {&quot;PKCS12:/path/to/blah&quot;: {&quot;user-pin-locked&quot;: false, &quot;user-pin-count-low&quot;: false}}}<br /> '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like? '''YES'''; the API will need to reflect what is exposed in the challange, and how it is exposed.<br /> <br /> '''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5050 2013-01-24T23:18:48Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;warnings&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;PIN count low&quot;}}<br /> This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values. Another option is to just expose the &quot;flags&quot; value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;token-flags&quot;: {&quot;PKCS12:/path/to/blah&quot;: 76}}<br /> Another option is to expose selected flags as keys in an object which maps them to booleans:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;], &quot;info&quot;: {&quot;PKCS12:/path/to/blah&quot;: {&quot;user-pin-locked&quot;: false, &quot;user-pin-count-low&quot;: false}}}<br /> '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like? '''YES'''<br /> <br /> '''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5049 2013-01-24T18:59:31Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally, and for &quot;PKCS11&quot; identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?<br /> <br /> '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like?<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5018 2012-12-21T20:34:37Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information?<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=5017 2012-12-21T20:29:21Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>{{project-early}}<br /> <br /> ==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: [&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;]}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=4918 2012-10-23T20:56:31Z

<p>Nalin: /* Tentative Implementation */</p> <hr /> <div>==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;}}<br /> Suggested sample answer:<br /> {&quot;identities&quot;: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/ResponderForPKINIT&diff=4917 2012-10-23T20:31:41Z

<p>Nalin: Responder support for PKINIT</p> <hr /> <div>==Description==<br /> <br /> The addition of [[Projects/Responder]] support to libkrb5 allows clients to use a responder callback to answer questions posed by the password-based and OTP preauthentication mechanisms, all at once, and in doing so select which mechanisms can be used to send requests to a KDC.<br /> <br /> ==Problem==<br /> <br /> Support for using responder callbacks has not been implemented for PKINIT. Applications which wish to continue to support PKINIT need to continue to provide a prompter callback, which reduces the usefulness of the responder callback machinery.<br /> <br /> ==Proposal==<br /> <br /> Add support for filling in response items to the PKINIT plugin.<br /> <br /> ==Expected Behavior==<br /> <br /> The naive expectation, that PKINIT will also make use of an application's responder callback, will be the correct one.<br /> <br /> ==Design==<br /> <br /> Load identity information in two passes. The first will be done during the plugin's fill_response method, at which time the client will attempt to load all configured identities. Those which don't require a password or PIN to read their keying material will just succeed, and those which don't will be added to the list of identities which will be added to the response item set. The second pass will use answers from the response item set to load identities from their corresponding locations, or if there is no answer, attempt to use the prompter callback to solicit passwords and PINs, as it does now.<br /> <br /> ==Tentative Implementation==<br /> <br /> * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.<br /> * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass. Special care will be needed for &quot;DIR&quot; identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual &quot;FILE&quot; identities internally.<br /> * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback. Suggested sample challenge for a ''pkinit'' question:<br /> {identities: {&quot;PKCS12:/path/to/blah&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;}}<br /> Suggested sample answer:<br /> {identities: {&quot;PKCS12:/path/to/blah&quot;: &quot;foo&quot;, &quot;FILE:/path/to/cert,/path/to/key&quot;: &quot;bar&quot;}}<br /> * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer. If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.<br /> <br /> ==Testing==<br /> <br /> * We'll need to add authenticated-client cases to the PKINIT tests, using keying material that's encrypted.<br /> * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.<br /> * We'll need to run tests using both encrypted and unencrypted copies of the keying material.<br /> <br /> ==Documentation==<br /> <br /> If we enumerate which in-tree preauth mechanisms use responder callbacks, PKINIT will need to be removed from a list of exceptions, if there is one, and added to the list of mechanisms which use responder callbacks.<br /> <br /> ==Release notes==<br /> <br /> Like documentation, to whatever extent we note that PKINIT doesn't support responder callbacks, we'll need to correct the notes.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4907 2012-10-17T21:42:30Z

<p>Nalin: /* Implementation */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the preauth challenge type which the client attempted to produce to send to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_type'', on a per-service-principal basis).<br /> * Provide a means of reading this value from a ccache and displaying it.<br /> * When a preauth challenge type is found in an input ccache, only call preauth mechanisms which will claim to be able to produce padata which corresponds to that type. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the previously-used preauth type and the currently-being-used preauth type.<br /> * Add a read_allowed_preauth_type() helper to retrieve the previously-used value before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a previously-used preauth type, skip over plugins which don't handle that type. Reset the value, so that it appears unset (i.e., holding the value ''KRB5_PADATA_NONE'') before processing a KDC response, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-supplied padata type to the ccache right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_retrieve_signer_identity() function and save the value it returns as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to fill in response questions, have it retrieve ''vendor'', ''algID'', and ''tokenID'' configuration values from the input_ccache using the new clpreauth callback, and if exactly one tokeninfo is found which matches all of the values which were retrieved, prune from its list of tokeninfos all other entries.<br /> * After the OTP client generates a request, save all of the vendor name, algorithm ID, and token ID, or rather all of those which the KDC supplied, as ''vendor'', ''algID'', and ''tokenID'' values in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth type set to 138 (''encrypted_challenge''), without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth type set to 2 (''encrypted_timestamp''), with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth type set to 138, with FAST enabled.<br /> *** Expected to succeed.<br /> *** Expect saved preauth type to indicate encrypted_challenge.<br /> ** Preauth type set to 2, without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth type to indicate encrypted_timestamp.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4904 2012-10-15T22:28:58Z

<p>Nalin: /* Testing */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the preauth challenge type which the client attempted to produce to send to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_type'', on a per-service-principal basis).<br /> * Provide a means of reading this value from a ccache and displaying it.<br /> * When a preauth challenge type is found in an input ccache, only call preauth mechanisms which will claim to be able to produce padata which corresponds to that type. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the previously-used preauth type and the currently-being-used preauth type.<br /> * Add a read_allowed_preauth_type() helper to retrieve the previously-used value before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a previously-used preauth type, skip over plugins which don't handle that type. Reset the value, so that it appears unset (i.e., holding the value ''KRB5_PADATA_NONE'') before processing a KDC response, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-supplied padata type to the ccache right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_retrieve_signer_identity() function and save the value it returns as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to fill in response questions, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune from its list of tokeninfos any which contain different vendor names.<br /> * After the OTP client selects a token, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth type set to 138 (''encrypted_challenge''), without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth type set to 2 (''encrypted_timestamp''), with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth type set to 138, with FAST enabled.<br /> *** Expected to succeed.<br /> *** Expect saved preauth type to indicate encrypted_challenge.<br /> ** Preauth type set to 2, without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth type to indicate encrypted_timestamp.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4903 2012-10-15T22:25:50Z

<p>Nalin: /* Implementation */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the preauth challenge type which the client attempted to produce to send to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_type'', on a per-service-principal basis).<br /> * Provide a means of reading this value from a ccache and displaying it.<br /> * When a preauth challenge type is found in an input ccache, only call preauth mechanisms which will claim to be able to produce padata which corresponds to that type. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the previously-used preauth type and the currently-being-used preauth type.<br /> * Add a read_allowed_preauth_type() helper to retrieve the previously-used value before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a previously-used preauth type, skip over plugins which don't handle that type. Reset the value, so that it appears unset (i.e., holding the value ''KRB5_PADATA_NONE'') before processing a KDC response, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-supplied padata type to the ccache right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_retrieve_signer_identity() function and save the value it returns as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to fill in response questions, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune from its list of tokeninfos any which contain different vendor names.<br /> * After the OTP client selects a token, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4902 2012-10-15T22:22:07Z

<p>Nalin: /* Design */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the preauth challenge type which the client attempted to produce to send to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_type'', on a per-service-principal basis).<br /> * Provide a means of reading this value from a ccache and displaying it.<br /> * When a preauth challenge type is found in an input ccache, only call preauth mechanisms which will claim to be able to produce padata which corresponds to that type. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the list of previously-used preauth types and the list of currently-being-used preauth types.<br /> * Add a read_allowed_preauth_types() helper to retrieve the previously-used list before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a list of previously-used preauth types, skip over plugins for types that aren't in the list. Make sure the list is clear, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * Add a create_selected_preauth_types() helper to rebuild the currently-being-used list before sending a KDC request.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-used list to it right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_retrieve_signer_identity() function and save the value it returns as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to make a request, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune tokeninfos which contain different vendor names before deciding whether or not the user needs to be asked to select one.<br /> * After the OTP client creates a challenge, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4899 2012-10-11T19:56:17Z

<p>Nalin: /* Implementation */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the list of preauth challenge types sent to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_types'', on a per-service-principal basis).<br /> * Provide a means of reading this list from a ccache and displaying it.<br /> * When a list of preauth challenge types is found in an input ccache, limit the types of preauth data the client will attempt to generate for the KDC to types from that list. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the list of previously-used preauth types and the list of currently-being-used preauth types.<br /> * Add a read_allowed_preauth_types() helper to retrieve the previously-used list before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a list of previously-used preauth types, skip over plugins for types that aren't in the list. Make sure the list is clear, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * Add a create_selected_preauth_types() helper to rebuild the currently-being-used list before sending a KDC request.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-used list to it right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_retrieve_signer_identity() function and save the value it returns as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to make a request, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune tokeninfos which contain different vendor names before deciding whether or not the user needs to be asked to select one.<br /> * After the OTP client creates a challenge, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4898 2012-10-11T19:29:12Z

<p>Nalin: /* Implementation */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the list of preauth challenge types sent to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_types'', on a per-service-principal basis).<br /> * Provide a means of reading this list from a ccache and displaying it.<br /> * When a list of preauth challenge types is found in an input ccache, limit the types of preauth data the client will attempt to generate for the KDC to types from that list. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the list of previously-used preauth types and the list of currently-being-used preauth types.<br /> * Add a read_allowed_preauth_types() helper to retrieve the previously-used list before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a list of previously-used preauth types, skip over plugins for types that aren't in the list. Make sure the list is clear, so that any plugin can assist in processing the AS-REP, before running through the list while processing a KDC reply.<br /> * Add a create_selected_preauth_types() helper to rebuild the currently-being-used list before sending a KDC request.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-used list to it right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_update_signer_identity() function to store that identity's name in a location where crypto_retrieve_signer_identity() can be used to retrieve it later, after we've verified that it worked.<br /> * If pkinit preauth succeeds, save the client identity that was used as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to make a request, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune tokeninfos which contain different vendor names before deciding whether or not the user needs to be asked to select one.<br /> * After the OTP client creates a challenge, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4897 2012-10-11T19:28:42Z

<p>Nalin: /* Implementation */</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the list of preauth challenge types sent to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_types'', on a per-service-principal basis).<br /> * Provide a means of reading this list from a ccache and displaying it.<br /> * When a list of preauth challenge types is found in an input ccache, limit the types of preauth data the client will attempt to generate for the KDC to types from that list. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the list of previously-used preauth types and the list of currently-being-used preauth types.<br /> * Add a read_allowed_preauth_types() helper to retrieve the previously-used list before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins to produce a KDC request, if we have a list of previously-used preauth types, skip over plugins for types that aren't in the list. Make sure the list is clear before running through the list while processing a KDC reply.<br /> * Add a create_selected_preauth_types() helper to rebuild the currently-being-used list before sending a KDC request.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-used list to it right after saving the ''fast_avail'' info.<br /> <br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_update_signer_identity() function to store that identity's name in a location where crypto_retrieve_signer_identity() can be used to retrieve it later, after we've verified that it worked.<br /> * If pkinit preauth succeeds, save the client identity that was used as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> <br /> * When the OTP client prepares to make a request, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune tokeninfos which contain different vendor names before deciding whether or not the user needs to be asked to select one.<br /> * After the OTP client creates a challenge, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin https://k5wiki.test.kerberos.org/wiki?title=Projects/Input_CCache&diff=4896 2012-10-11T19:15:10Z

<p>Nalin: New page: ==Background== The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial c...</p> <hr /> <div>==Background==<br /> <br /> The addition of preauth mechanisms which aren't password-based to the Kerberos protocol leads to a more complicated user experience when a user attempts to obtain initial credentials.<br /> <br /> When PKINIT is in use, this can include prompting the user for a password needed for accessing encrypted keying material and for a PIN for logging in to a cryptographic token. Depending on the system configuration, a user may be prompted several times for this information for multiple candidate identities.<br /> <br /> When OTP tokens are used, the user may also be required to first select which token to use.<br /> <br /> ==Problem==<br /> <br /> In some applications, particularly in screen unlocking, asking or permitting the user to reauthenticate in a different manner than was used for initial login confuses people.<br /> <br /> ==Goals==<br /> <br /> The least surprising behavior in that scenario is to attempt to repeat the authentication choices which were made at the time the user logged in: if the user used a smart card, ideally the user would only be prompted for that same card's PIN, but if the user used a password, the presence of a smart card in a reader attached to the system would be ignored.<br /> <br /> To that end, the intent is to provide a way for an application to indicate to the client library that it would like to use the same preauth mechanism that was used to obtain a previously-obtained TGT, and to provide a means of allowing mechanisms to record non-sensitive information which will allow them to reduce the number of requests they make to the user. For PKINIT and OTP mechanisms, for example, this would involve caching credential or token selection information, but not PIN or password values.<br /> <br /> ==Design==<br /> <br /> This feature has several parts:<br /> * Add an &quot;input&quot; ccache get_init_creds option.<br /> * While input ccaches won't be used by default, give kinit a way to specify one.<br /> * Save the list of preauth challenge types sent to the KDC to an output ccache when credentials are successfully obtained (working name ''pa_types'', on a per-service-principal basis).<br /> * Provide a means of reading this list from a ccache and displaying it.<br /> * When a list of preauth challenge types is found in an input ccache, limit the types of preauth data the client will attempt to generate for the KDC to types from that list. This will alter the client's behavior to skip over mechanisms which weren't used the last time.<br /> * Add client preauth plugin callbacks for setting data items that will be stored to the ccache if credentials are obtained (working name ''pa_config_data'', on a per-server-principal basis), and for reading them when called to generate preauth data.<br /> * Modify the PKINIT plugin to use this facility to save the client's chosen identity while generating PKINIT AS-REQ data (working name ''X509_user_identity'', despite being handled differently than the preauth option of the same name).<br /> * Modify the PKINIT plugin to check for this saved value, and if one is found, to bypass the default searching of multiple possible client identities in favor of the recorded value.<br /> * Modify the OTP plugin to use this facility to save information sufficient to identify which token is being used while generating OTP AS-REQ data (proposed name ''vendor'').<br /> * Modify the OTP plugin to use this facility to check for this saved value, and if one is found, to use it to decide which token's code it should request the user to provide.<br /> <br /> ==Implementation==<br /> <br /> * Add a krb5_get_init_creds_opt_set_in_ccache() function and a field in the krb5_get_init_creds_opt's private area to store the value.<br /> * Add a -I flag to kinit to allow an input ccache to be supplied, expected to be used mainly for troubleshooting.<br /> <br /> * Modify the client preauth rock to add a field to hold the list of previously-used preauth types and the list of currently-being-used preauth types.<br /> * Add a read_allowed_preauth_types() helper to retrieve the previously-used list before generating preauth data when sending a KDC request.<br /> * When running through the list of preauth plugins, if we have a list of previously-used preauth types, skip over plugins for types that aren't in the list. Make sure the list is clear before running through the list while processing a KDC reply.<br /> * Add a create_selected_preauth_types() helper to rebuild the currently-being-used list before sending a KDC request.<br /> * If we successfully process a KDC reply, and we have an out_ccache, save the currently-being-used list to it right after saving the ''fast_avail'' info.<br /> <br /> * Modify the client preauth rock to add a field to hold the preauth config data that was read from an in_ccache, and another to hold preauth config data that will be saved to an out_ccache.<br /> * Add a reset_cc_config_data() helper to retrieve the previously-saved preauth config data and reset the to-be-saved preauth config data before generating preauth data when sending a KDC request.<br /> * Add client preauth callbacks to retrieve an item from the previously-saved preauth config data or add an item to the to-be-saved preauth config data.<br /> <br /> * Teach PKINIT to not discard the names of client identities after loading them.<br /> * When reading PKINIT configuration, try to retrieve a ''X509_user_identity'' configuration value from an input ccache. If one is found, short-circuit the selection process, as the server does with its configured value.<br /> * After selecting a specific identity, have pkinit call a new crypto_update_signer_identity() function to store that identity's name in a location where crypto_retrieve_signer_identity() can be used to retrieve it later, after we've verified that it worked.<br /> * If pkinit preauth succeeds, save the client identity that was used as a ''X509_user_identity'' configuration value using the new clpreauth callback.<br /> <br /> * When the OTP client prepares to make a request, have it retrieve a ''vendor'' configuration value from the input_ccache using the new clpreauth callback, and if one is found, prune tokeninfos which contain different vendor names before deciding whether or not the user needs to be asked to select one.<br /> * After the OTP client creates a challenge, save the vendor name from the tokeninfo which was used as a ''vendor'' value in the out_ccache.<br /> <br /> ==Testing==<br /> <br /> * A test program will be needed. It will need to be able to<br /> ** Read or write (overwrite) stored configuration data used by preauth plugins.<br /> ** Attempt to obtain credentials, answering prompts using pre-supplied answers.<br /> ** Report status.<br /> * Expected tests:<br /> ** Preauth types list set to [encrypted_challenge], without FAST.<br /> *** Expected to fail because encrypted_challenge won't be offered by the KDC when FAST isn't being used.<br /> ** Preauth types list set to [encrypted_challenge,OTP], without FAST.<br /> *** Expected to fail because neither mechanism will be offered by the KDC.<br /> ** Preauth types list set to [encrypted_timestamp], with FAST enabled.<br /> *** Expected to fail because encrypted_timestamp won't be available when FAST is being used.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], without FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_timestamp.<br /> ** Preauth types list set to [encrypted_challenge,encrypted_timestamp, OTP], with FAST.<br /> *** Expected to succeed.<br /> *** Expect saved preauth types list to include encrypted_challenge.<br /> <br /> ==Documentation==<br /> <br /> * Man page for kinit's new use-an-in-ccache -I flag.<br /> * Man page for klist's new show-config-data -C flag.<br /> * In-header documentation for new krb5_get_init_creds_opt_set_in_ccache().<br /> * In-header documentation for new client preauth callbacks.<br /> <br /> ==Release Notes==<br /> * Developer experience:<br /> ** Adds a krb5_get_init_creds_opt_set_in_ccache() option.<br /> ** Adds get_cc_config_data() and set_cc_config_data() clpreauth callbacks for getting string attribute values from an ''in_ccache'' and storing them in an ''out_ccache'', respectively.</div>

Nalin