>>>>> "Robie" == Robie Basak <1643...@bugs.launchpad.net> writes:
Robie> @Bruce Thank you for detailing your testing. In your test
Robie> suite, do you cover any interoperability with SPNEGO but
Robie> not-Windows, whether in integration or code path coverage?
Robie> That's the use case I'm concerned about - that someone will
Robie> come along and tell us that we regressed SPNEGO against
Robie> WebSphere or something because we focused on just testing
Robie> Windows.
Hi.
As I understand it, this is a backport of an upstream change.
It's always possible there is an interop regression.
In this instance though, given where the patch comes from originally,
and that it's been in upstream releases for a while, I think you're
relatively safe.
SPNEGO interop is really hard to test though; it's not something that
you can get good coverage for without a specific interoperability lab
and careful test plans.
I don't know if upstream has done that for this patch, although I do
have high confidence that people do interop tests against the upstream
version.
So, while I think your concern is reasonable, I'd urge you to consider
that you're setting a really high bar here for backporting a patch that
an interoperability-conscious upstream has vetted.
Yes, the MIT folks have messed up interop (just as everyone else), but
they are fairly careful and conservative.
If you do want to do interop testing, the interesting cases to cover
are:
* Initiator prefers Kerberos; other side does not support it
* Acceptor prefers Kerberos, initiator does not support it
* Initiator prefers NTLM and some non-Kerberos third mechanism
* Acceptor prefers NTLM, doesn't have Kerberos, but does have some third
mechanism
I think setting all that up is a good week's worth of work with someone
who really knows what they are doing.
--Sam
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1643708
Title:
Add SPNEGO special case for NTLMSSP+MechListMIC
Status in krb5 package in Ubuntu:
Fix Released
Status in krb5 source package in Trusty:
Fix Committed
Status in krb5 source package in Xenial:
Fix Committed
Status in krb5 source package in Yakkety:
Fix Committed
Bug description:
[Impact]
MS-SPNG section 3.3.5.1 documents an odd behavior the SPNEGO layer
needs to implement specifically for the NTLMSSP mechanism. This is
required for compatibility with Windows services.
Upstream commit:
https://github.com/krb5/krb5/commit/cb96ca52a3354e5a0ea52e12495ff375de54f9b7
We've run into this issue with Linux to Windows negotiation with
encrypted http using GSSAPI.
[Test Case]
create a file with some credentials:
$ echo F23:guest:guest > ~/ntlmcreds.txt
$ export NTLM_USER_FILE=~/ntlmcreds.txt
$ python
import gssapi
spnego = gssapi.raw.oids.OID.from_int_seq('1.3.6.1.5.5.2')
c = gssapi.creds.Credentials(mechs=[spnego], usage='initiate')
tname = gssapi.raw.names.import_name("F23/server",
name_type=gssapi.raw.types.NameType.hostbased_service)
ac = gssapi.creds.Credentials(mechs=[spnego], usage='accept')
seci = gssapi.SecurityContext(creds=c, name=tname, mech=spnego,
usage='initiate')
seca = gssapi.SecurityContext(creds=ac, usage='accept')
it = seci.step(token=None)
ot = seca.step(token=it)
it = seci.step(token=ot)
ot = seca.step(token=it)
it = seci.step(token=ot)
e = seci.wrap("Secrets", True)
o = seca.unwrap(e.message)
o.message
'Secrets'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1643708/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
