negoex

One note is that our current NegoEx implementation uses the presence of a mechanism's gss_query_mechanism_info() to determine whether it supports NegoEx or not. If we infer the GUID and the key derivation function, then we either need to:

* advertise all mechanisms via NegoEx (with some hard-coded exceptions for SPNEGO, Kerberos, NTLM)
* use a mechanism attribute to determine which are to be advertised
* something else

We'd need to think a bit about this.
I'd assume we'd use the presence or absence of a mechanism attribute.

But you also need to think about the negotiation tokens and how you get
those for credential selection and the like.
-
--Sam

Adding the attribute-based support wouldn't be too hard. I suppose we'd still want to keep the ability for a mechanism to specify its own GUID and key derivation function, because we don't know what MS are doing for PKU2U (it's almost certainly not what one might propose in the IETF). So it could be either/or.

Don't forget there is code for NegoEx in PADL's github.

I know.
I need to look at the negoex draft and your code and comment.

It's behind abfab updates and getting moonshot building and preparing
for meetings with Josh.

Well we shipped the SSP with NegoEx so we're likely stuck with those choices for interop.

Sent from my iPhone

> On 28 Apr 2017, at 18:29, Mark Donnelly <email address hidden> wrote:
>
> ** Changed in: moonshot
> Importance: Low => Wishlist
>
> --
> You received this bug notification because you are a member of Moonshot
> Drivers, which is subscribed to Project Moonshot.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/903355
>
> Title:
> negoex
>
> Status in Project Moonshot:
> Confirmed
>
> Bug description:
> Currently we have the mechanism-side information to provide for NegoEX.
> We're the first standardized mechanism for which negoex will be used; it is basically not used for krb5.
>
> Discussions with Microsoft about how to address issued raised against
> the negoex spec suggested that there may be some protocol
> restrications about how it is used when standardized by the IETF.
> Examples include:
>
> * Key derivation possibly/probably using gss_pseudo_random to produce the integrity key required by negoex
> * derivation of the guid from the oid in some algorithmic manner.
>
> Obviously mechanism glue layers would need to have ways to bypass these for people implementing existing proprietary mechanisms.
> However, we may not be able to get that to fly in a standard.
> We should either stub out making our negoex accessible or have confidence that the IETF is happy with how we do things prior to the service pilot.
> Nico and others rasied concerns about some issues in negoex
> * key derivation for the RFC 3961 key used for integrity
> (* use of guids
>
> A proposal has been on the table for fixing these at least for standards track mechanisms
> * Specify key derivations in terms of a call to gss_pseudo_random
> * derive guids from the OID
>
> Clearly mechglues would need to be able to bypass that for existing proprietary mechanisms.
> However, we're the first standardized mechanism that is going to use negoex. So we need to figure out what the IETf will allow us to standardze.
>
> We need to either stub out our negoex or convince ourselves it is OK prior to service pilot.
> Note that we could also just convince ourselves we have a transition strategy to supporting our old stuff and whatever the IETF comes up with.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/903355/+subscriptions