#914 Make TCP a preffered protocol for communication with KDC
Closed: Invalid None Opened 12 years ago by sgallagh.

We should step through the various stages of authentication ourselves, rather than relying on krb5_init_creds_password() to do it all for us.

This will allow us to handle timeouts properly when dealing with two-factor authentication that relies on a long delay (such as sending a text message to a user's cellphone) which would otherwise time out.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

This is out of the scope of the 1.8 release.

milestone: SSSD 1.8.0 => SSSD 1.9.0
rhbz: =>

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Kerberos improvements

Fields changed

priority: major => critical

Fields changed

rhbz: => 0

Fields changed

feature_milestone: =>
proposed_priority: => Core

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD Kerberos Improvements Feature => SSSD 1.10 beta

Fields changed

design: =>
design_review: => 0
fedora_test_page: =>
summary: Use krb5_init_creds_init() and krb5_init_creds_step() => [RFE] Use krb5_init_creds_init() and krb5_init_creds_step()

Fields changed

selected: => May

Fields changed

priority: critical => major

Fields changed

milestone: SSSD 1.10 beta => SSSD 1.11 beta
owner: somebody => npmccallum

After some investigation, I don't think this change is actually needed.

First, let's consider how this change might be useful. If the server were to take a long time (minutes) to validate a request, the KDC could provide a "still processing" error code. This error code would indicate to the client to try again after a certain time.

Unfortunately, no such error code exists. Thus, SSSD has no way to determine whether the server is (knowingly) taking a long time or something much worse has happened. The existing code handles this case.

Even if krb5 had such an error code, it would not be very useful in the OTP case. In the krb5 OTP preauth protocol, there is a two pass and a four pass variant. MIT krb5 only supports the four pass variant (and is not likely to ever support the two pass one). In the four pass variant, an initial request is sent to the server and a challenge is received back (roundtrip 1). The client then enters its credentials as padata and re-submits the request (roundtrip 2). In the case of a text message going to a cell phone, the text message would be sent during roundtrip 1. Once the user received the code, they would type it in and roundtrip 2 would occur. Thus, all the waiting is on the client side, not the server.

In short, I see no current case where a change from krb5_get_init_creds_password() to krb5_get_init_creds_step() would actually provide a real benefit.

review: => 0

In the MIT weekly call we discussed the problems of lockouts that might arise in the case of intentional long (state synchronization) delays on the part of servers. We discussed a variety of scenarios listed below:

Problem - If an OTP server receives multiple requests, accounts will likely
be locked. The current timeout/retry behavior of libkrb5 is also likely
to exacerbate this problem.

Solution 1 - Use krb5_get_init_creds_step().
This would allow SSSD to define its own dynamic timeouts. Unfortunately,
it doesn't fix the problem for everyone, most notably kinit. REJECTED

Solution 2 - Make timeouts configurable.
This too requires changes to every client. It is also not really
flexible. REJECTED

Solution 3 - Filter out duplicate requests in the companion daemon.
Would require a properly locked lookaside cache. Doesn't solve the
problem across multiple KDCs. REJECTED

Solution 4 - Raise default timeout in libkrb5
Too inflexible; also, not the right behavior in many cases. REJECTED

Solution 5 - Raise timeout and/or use TCP if doing preauth
The code for this solution would be difficult. Not likely for 1.12.
REJECTED

Solution 6 - Manually configure TCP; fix TCP connection behavior
FreeIPA already configures TCP by default so no change is required. The
only code that needs to change is that once a TCP connection is
established:
1. No other KDCs are contacted
2. Timeout is increased to 10s
This change is arguably the correct default behavior for TCP anyway and
is simpler than trying to detect preauth. ACCEPTED

This behavior has now been committed in upstream libkrb5: https://github.com/krb5/krb5/commit/f423c28a68e94e1aac2b40bb9902a017d2b0c83e

This patch depends on a set of four patches (itself and the three previous).

As stated in the previous comment, no real-world cases of this problem are yet known. But if they are discovered, it may be possible to backport from or upgrade to krb5 1.12.

Fields changed

milestone: SSSD 1.11 beta => NEEDS_TRIAGE

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10.0
summary: [RFE] Use krb5_init_creds_init() and krb5_init_creds_step() => [RFE] Make TCP preffer communication choice

Fields changed

summary: [RFE] Make TCP preffer communication choice => [RFE] Make TCP a preffered protocol for communication with KDC

No user visible effect.

changelog: =>
summary: [RFE] Make TCP a preffered protocol for communication with KDC => Make TCP a preffered protocol for communication with KDC
type: enhancement => task

Fields changed

milestone: SSSD 1.10.0 => SSSD 1.10.1

Moving tickets that didn't make 1.10.1 to the 1.10.2 bucket.

Moving tickets that didn't make 1.10.1 to 1.10.2

milestone: SSSD 1.10.1 => SSSD 1.10.2

Lukas knows the Kerberos API well enough and was already looking into the ticket.

owner: npmccallum => lslebodn

We're still investigating how to prefer TCP on the libkrb5 level. Moving to 1.11.2

milestone: SSSD 1.10.2 => SSSD 1.11.2

Fields changed

owner: lslebodn => nalin

Nathaniel posted a patch to freeipa-devel

owner: nalin => npmccallum
patch: 0 => 1

Closing, will be handled on the IPA side

resolution: => wontfix
status: new => closed

Metadata Update from @sgallagh:
- Issue assigned to npmccallum
- Issue set to the milestone: SSSD 1.11.2

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1956

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata