https://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&feed=atom&action=historyProjects/Graceful recovery after destructive service rekey - Revision history2024-03-28T19:15:08ZRevision history for this page on the wikiMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&diff=5965&oldid=prevGhudson at 17:39, 2 April 20192019-04-02T17:39:20Z<p></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 17:39, 2 April 2019</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 17:</td>
<td colspan="2" class="diff-lineno">Line 17:</td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* Most current ccache types do not support a way to remove a credential, and it is difficult to do so within a file ccache (although Heimdal has an approach where the credential is modified in a way that makes it unlikely to be matched). If we try to work around this by reinitializing the ccache and copying all of the other credentials, we run into {{bug|7707}}.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* Most current ccache types do not support a way to remove a credential, and it is difficult to do so within a file ccache (although Heimdal has an approach where the credential is modified in a way that makes it unlikely to be matched). If we try to work around this by reinitializing the ccache and copying all of the other credentials, we run into {{bug|7707}}.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker">−</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>* If there is propagation delay between master and <del class="diffchange diffchange-inline">slave</del> KDCs, re-fetching the service ticket may just get us another out-of-date ticket, unless we somehow make sure to use the master KDC (which is not supported by current APIs). This problem could be considered out of scope.</div></td>
<td class="diff-marker">+</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>* If there is propagation delay between master and <ins class="diffchange diffchange-inline">replica</ins> KDCs, re-fetching the service ticket may just get us another out-of-date ticket, unless we somehow make sure to use the master KDC (which is not supported by current APIs). This problem could be considered out of scope.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* We could be in a situation where the KDC consistently gives us a service ticket which produces a KRB5_AP_ERR_BADKEYVER result, no matter how many times we refresh it. This could happen because of the above problem or because of a misconfiguration. If we discard the service ticket over and over again, we could generate a lot of TGS requests we wouldn't otherwise generate. From the KDC's perspective this is not necessarily any worse than the performance issues which result from not having negative caching of TGS requests, but on the client it could also cause a file ccache to grow each time we try to authenticate.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* We could be in a situation where the KDC consistently gives us a service ticket which produces a KRB5_AP_ERR_BADKEYVER result, no matter how many times we refresh it. This could happen because of the above problem or because of a misconfiguration. If we discard the service ticket over and over again, we could generate a lot of TGS requests we wouldn't otherwise generate. From the KDC's perspective this is not necessarily any worse than the performance issues which result from not having negative caching of TGS requests, but on the client it could also cause a file ccache to grow each time we try to authenticate.</div></td>
</tr>
</table>Ghudsonhttps://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&diff=5337&oldid=prevGhudson at 17:28, 1 July 20142014-07-01T17:28:41Z<p></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 17:28, 1 July 2014</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 11:</td>
<td colspan="2" class="diff-lineno">Line 11:</td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The client only discovers that its service ticket is out of date when it receives a KRB_AP_ERR_BADKEYVER error from the receiver. At this point, to retry within the library, we would need to extend {{rfcref|4121}}, with consequent issues of endpoint negotiation and application compatibility. Without extending the krb5 mech, the best we can do is make the next attempt at authentication work.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The client only discovers that its service ticket is out of date when it receives a KRB_AP_ERR_BADKEYVER error from the receiver. At this point, to retry within the library, we would need to extend {{rfcref|4121}}, with consequent issues of endpoint negotiation and application compatibility. Without extending the krb5 mech, the best we can do is make the next attempt at authentication work.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker">−</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>* Since 1.7, the server returns KRB_AP_WRONG_PRINC instead of KRB_AP_ERR_BADKEYVER on a key version mismatch; see {{bug|7232}}. This can be fixed for simple cases, but if the ticket uses an alias for the server, it is not always possible to tell whether the client presented a ticket with the wrong kvno or just a ticket for the wrong server principal.</div></td>
<td class="diff-marker">+</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>* Since 1.7, the server returns KRB_AP_WRONG_PRINC instead of KRB_AP_ERR_BADKEYVER on a key version mismatch; see {{bug|7232}}. This can be fixed for simple cases, but if the ticket uses an alias for the server, it is not always possible to tell whether the client presented a ticket with the wrong kvno or just a ticket for the wrong server principal.<ins class="diffchange diffchange-inline"> (Update: the simple case will be addressed in 1.13 by {{bug|7232}}.)</ins></div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* There is no authentication of errors in an AP exchange, so we have to consider the possibility of an attacker forcing the client to discard its service ticket, although there are probably no interesting attacks.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* There is no authentication of errors in an AP exchange, so we have to consider the possibility of an attacker forcing the client to discard its service ticket, although there are probably no interesting attacks.</div></td>
</tr>
</table>Ghudsonhttps://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&diff=5294&oldid=prevGhudson: /* Obstacles */2014-04-28T15:04:12Z<p><span dir="auto"><span class="autocomment">Obstacles</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 15:04, 28 April 2014</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 11:</td>
<td colspan="2" class="diff-lineno">Line 11:</td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The client only discovers that its service ticket is out of date when it receives a KRB_AP_ERR_BADKEYVER error from the receiver. At this point, to retry within the library, we would need to extend {{rfcref|4121}}, with consequent issues of endpoint negotiation and application compatibility. Without extending the krb5 mech, the best we can do is make the next attempt at authentication work.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The client only discovers that its service ticket is out of date when it receives a KRB_AP_ERR_BADKEYVER error from the receiver. At this point, to retry within the library, we would need to extend {{rfcref|4121}}, with consequent issues of endpoint negotiation and application compatibility. Without extending the krb5 mech, the best we can do is make the next attempt at authentication work.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker">−</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>* Since 1.7, the server returns KRB_AP_WRONG_PRINC instead of KRB_AP_ERR_BADKEYVER on a key version mismatch; see {{bug|7232}}. This can be fixed.</div></td>
<td class="diff-marker">+</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>* Since 1.7, the server returns KRB_AP_WRONG_PRINC instead of KRB_AP_ERR_BADKEYVER on a key version mismatch; see {{bug|7232}}. This can be fixed<ins class="diffchange diffchange-inline"> for simple cases, but if the ticket uses an alias for the server, it is not always possible to tell whether the client presented a ticket with the wrong kvno or just a ticket for the wrong server principal</ins>.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* There is no authentication of errors in an AP exchange, so we have to consider the possibility of an attacker forcing the client to discard its service ticket, although there are probably no interesting attacks.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* There is no authentication of errors in an AP exchange, so we have to consider the possibility of an attacker forcing the client to discard its service ticket, although there are probably no interesting attacks.</div></td>
</tr>
</table>Ghudsonhttps://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&diff=5281&oldid=prevGhudson: /* Obstacles */2014-03-07T17:43:41Z<p><span dir="auto"><span class="autocomment">Obstacles</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 17:43, 7 March 2014</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 19:</td>
<td colspan="2" class="diff-lineno">Line 19:</td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* If there is propagation delay between master and slave KDCs, re-fetching the service ticket may just get us another out-of-date ticket, unless we somehow make sure to use the master KDC (which is not supported by current APIs). This problem could be considered out of scope.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* If there is propagation delay between master and slave KDCs, re-fetching the service ticket may just get us another out-of-date ticket, unless we somehow make sure to use the master KDC (which is not supported by current APIs). This problem could be considered out of scope.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker">−</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>* We could be in a situation where the KDC consistently gives us a service ticket which produces a KRB5_AP_ERR_BADKEYVER result, no matter how many times we refresh it. This could happen because of the above problem or because of a misconfiguration. If we discard the service ticket over and over again, we could generate a lot of TGS requests we wouldn't otherwise generate. <del class="diffchange diffchange-inline">This</del> is not necessarily any worse than the performance issues which result from not having negative caching of TGS requests.</div></td>
<td class="diff-marker">+</td>
<td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>* We could be in a situation where the KDC consistently gives us a service ticket which produces a KRB5_AP_ERR_BADKEYVER result, no matter how many times we refresh it. This could happen because of the above problem or because of a misconfiguration. If we discard the service ticket over and over again, we could generate a lot of TGS requests we wouldn't otherwise generate. <ins class="diffchange diffchange-inline">From the KDC's perspective this</ins> is not necessarily any worse than the performance issues which result from not having negative caching of TGS requests<ins class="diffchange diffchange-inline">, but on the client it could also cause a file ccache to grow each time we try to authenticate</ins>.</div></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td>
</tr>
<tr>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The above scenario could be mitigated by annotating a service ticket when it works, and then only discarding it if the ticket if it worked at least once and then started to fail. The benefit is that we would avoid retry loops; the cost is that we wouldn't get graceful recovery in the unlikely event that a service is re-keyed between the client getting a service ticket and its first use. The ccache API currently provides no way to annotate a ticket, so we would have to add that capability or abuse ccache config entries to fake it.</div></td>
<td class="diff-marker"> </td>
<td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>* The above scenario could be mitigated by annotating a service ticket when it works, and then only discarding it if the ticket if it worked at least once and then started to fail. The benefit is that we would avoid retry loops; the cost is that we wouldn't get graceful recovery in the unlikely event that a service is re-keyed between the client getting a service ticket and its first use. The ccache API currently provides no way to annotate a ticket, so we would have to add that capability or abuse ccache config entries to fake it.</div></td>
</tr>
</table>Ghudsonhttps://k5wiki.kerberos.org/wiki?title=Projects/Graceful_recovery_after_destructive_service_rekey&diff=5280&oldid=prevGhudson: New page: {{project-early}} ==Background== For some period of time after a service is re-keyed, clients may have cached credentials using the old version of the service key. Ideally, the server w...2014-03-06T21:26:05Z<p>New page: {{project-early}} ==Background== For some period of time after a service is re-keyed, clients may have cached credentials using the old version of the service key. Ideally, the server w...</p>
<p><b>New page</b></p><div>{{project-early}}<br />
<br />
==Background==<br />
<br />
For some period of time after a service is re-keyed, clients may have cached credentials using the old version of the service key. Ideally, the server will retain the old key versions for as long as there might be outstanding tickets. If a server is completely re-provisioned or replaced, it may be impractical to retain the old keytab. In this case, the usual practice is for users to manually refresh their ticket caches (by running kinit) to discard service tickets, which is inconvenient. It would be better if the client library code could automatically discard the cached service ticket and get a new one.<br />
<br />
==Obstacles==<br />
<br />
There are several obstacles to solving this problem as gracefully as we might like:<br />
<br />
* The client only discovers that its service ticket is out of date when it receives a KRB_AP_ERR_BADKEYVER error from the receiver. At this point, to retry within the library, we would need to extend {{rfcref|4121}}, with consequent issues of endpoint negotiation and application compatibility. Without extending the krb5 mech, the best we can do is make the next attempt at authentication work.<br />
<br />
* Since 1.7, the server returns KRB_AP_WRONG_PRINC instead of KRB_AP_ERR_BADKEYVER on a key version mismatch; see {{bug|7232}}. This can be fixed.<br />
<br />
* There is no authentication of errors in an AP exchange, so we have to consider the possibility of an attacker forcing the client to discard its service ticket, although there are probably no interesting attacks.<br />
<br />
* Most current ccache types do not support a way to remove a credential, and it is difficult to do so within a file ccache (although Heimdal has an approach where the credential is modified in a way that makes it unlikely to be matched). If we try to work around this by reinitializing the ccache and copying all of the other credentials, we run into {{bug|7707}}.<br />
<br />
* If there is propagation delay between master and slave KDCs, re-fetching the service ticket may just get us another out-of-date ticket, unless we somehow make sure to use the master KDC (which is not supported by current APIs). This problem could be considered out of scope.<br />
<br />
* We could be in a situation where the KDC consistently gives us a service ticket which produces a KRB5_AP_ERR_BADKEYVER result, no matter how many times we refresh it. This could happen because of the above problem or because of a misconfiguration. If we discard the service ticket over and over again, we could generate a lot of TGS requests we wouldn't otherwise generate. This is not necessarily any worse than the performance issues which result from not having negative caching of TGS requests.<br />
<br />
* The above scenario could be mitigated by annotating a service ticket when it works, and then only discarding it if the ticket if it worked at least once and then started to fail. The benefit is that we would avoid retry loops; the cost is that we wouldn't get graceful recovery in the unlikely event that a service is re-keyed between the client getting a service ticket and its first use. The ccache API currently provides no way to annotate a ticket, so we would have to add that capability or abuse ccache config entries to fake it.</div>Ghudson