Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11

From: Leif Johansson <[email-masked]>
Date: Sun, 13 Nov 2011 03:17:19 +0100

On 10/27/2011 05:18 PM, Nico Williams wrote:
> On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson <[email-masked]>
> wrote:
>>> GSS_Set_name_attribute() MAY succeed even though a credential
>>> acquired with the resulting NAME may not actually result in a
>>> peer seeing the given attribute.  If it is critical that the
>>> attribute be asserted in subsequent security context
>>> establishments, then the caller must inquire the NAME for any 
>>> CREDENTIAL HANDLE acquired with this NAME and then check that
>>> the requested attribute has indeed been set in the CREDENTIAL
>>> HANDLE's NAME.
>> 

So it sounds like there is consensus for Nicos proposal.

Do you want to call this now Shawn or should I bring it up at the
mic and re-confirm?

In either case I can have a version out as soon as Scotts issue
on persistent NameID has been resolved.

We should start a WGLC on that version asap.

	Cheers Leif

---

From: Shawn M Emery <[email-masked]>
Date: Sun, 13 Nov 2011 19:13:07 -0700

On 11/12/11 7:17 PM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson<[email-masked]>
>> wrote:

Let's discuss this during the session and then make a consensus call to 
the list in case there are any new revelations made.

> on persistent NameID has been resolved.

Thanks.

> We should start a WGLC on that version asap.

Agreed.

Shawn.
--

---

From: Leif Johansson <[email-masked]>
Date: Tue, 15 Nov 2011 10:29:22 +0100

Sam and me talked this over yesterday and we realized that we've
been talking about two different things and that both proposals
that have been discussed make sense.

We've been talking about unknown attributes in the sense that
no mechanism has knowledge of or supports the attribute type.
We are also talking about criticality in the sense that you
need to know for sure that an attribute has been set.

We propose to keep the current text that sais that an error
must be returned for unknown attributes *and* add the text
that Nico proposed that sais that if you care you must verify.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 16 Nov 2011 03:52:01 +0100

On 11/14/2011 03:13 AM, Shawn M Emery wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>>> GSS_Set_name_attribute() MAY succeed even though a
>>>>> credential acquired with the resulting NAME may not
>>>>> actually result in a peer seeing the given attribute.  If
>>>>> it is critical that the attribute be asserted in subsequent
>>>>> security context establishments, then the caller must
>>>>> inquire the NAME for any CREDENTIAL HANDLE acquired with
>>>>> this NAME and then check that the requested attribute has
>>>>> indeed been set in the CREDENTIAL HANDLE's NAME.
>> 
>> Do you want to call this now Shawn or should I bring it up at
>> the mic and re-confirm?
> 
> Let's discuss this during the session and then make a consensus
> call to the list in case there are any new revelations made.
> 

Expanding on my note from yesterday - here is suggested text for
section 7.6 (just after the list of error codes):

"If the attribute NAME is not know or could not be set an error of
GSS_S_UNAVAILABLE SHOULD be returned however GSS_Set_name_attribute()
MAY succeed even though a credential acquired with the resulting NAME
may not actually result in a peer seeing the given attribute. If it is
critical that the attribute be asserted in subsequent security context
establishments, then the caller must inquire the NAME for any
CREDENTIAL HANDLE acquired with this NAME and then check that the
requested attribute has indeed been set in the CREDENTIAL HANDLE's NAME."

If I can get a consensus for that I can issue 12 and Shawn can start
the (final?) WGLC.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Nov 2011 02:57:56 +0100

On 11/16/2011 04:00 AM, Alexey Melnikov wrote:
> On 16/11/2011 02:52, Leif Johansson wrote:
>>>>> On Thu, Oct 27, 2011 at 9:36 AM, Leif
>>>>> Johansson<[email-masked]> wrote:
>>>>>>> actually result in a peer seeing the given attribute.
>>>>>>> If it is critical that the attribute be asserted in
>>>>>>> subsequent security context establishments, then the
>>>>>>> caller must inquire the NAME for any CREDENTIAL HANDLE
>>>>>>> acquired with this NAME and then check that the
>>>>>>> requested attribute has indeed been set in the
>>>>>>> CREDENTIAL HANDLE's NAME.
>>>> Do you want to call this now Shawn or should I bring it up
>>>> at the mic and re-confirm?
>>> Let's discuss this during the session and then make a
>>> consensus call to the list in case there are any new
>>> revelations made.
>> "If the attribute NAME is not know
> s/know/known
>> or could not be set an error of GSS_S_UNAVAILABLE SHOULD be
>> returned however GSS_Set_name_attribute() MAY succeed even though
>> a credential acquired with the resulting NAME may not actually
>> result in a peer seeing the given attribute. If it is critical
>> that the attribute be asserted in subsequent security context 
>> HANDLE's NAME."
>> If I can get a consensus for that I can issue 12 and Shawn can
>> start the (final?) WGLC.
> The new text looks good to me.
> 

I got this reply from Alexei. Anyone else...? Going.... going....

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Nov 2011 21:27:32 -0600

> "If the attribute NAME is not know or could not be set an error of

s/know/known/

> GSS_S_UNAVAILABLE SHOULD be returned however GSS_Set_name_attribute()

I think I want s/SHOULD/may/ here because the only way the mechglue
could know if an attribute is "known" is by inquiring all its
providers to see if it is.  Sure, the SPI could have a method to do
the inquiry, but I'd not want to assume that.  Besides, given that we
agree that the caller that cares must check the acquired credential's
name, I don't want to give developers a false sense that they don't
have to.

> MAY succeed even though a credential acquired with the resulting NAME

But this MAY is fine :)

> If I can get a consensus for that I can issue 12 and Shawn can start

With the above corrections I think this is fine.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Nov 2011 06:37:49 +0100

On 11/17/2011 04:27 AM, Nico Williams wrote:
> I think I want s/SHOULD/may/ here because the only way the
> mechglue could know if an attribute is "known" is by inquiring all
> its providers to see if it is.  Sure, the SPI could have a method
> to do the inquiry, but I'd not want to assume that.  Besides, given
> that we agree that the caller that cares must check the acquired
> credential's name, I don't want to give developers a false sense
> that they don't have to.

The second MAY is pretty clear on that I think. A SHOULD says that
the mechglue is expected to do its best but that it MAY do something
else if it has good reason to. I suspect that most implementations
will have configuration to look at for determining that an attribute
is known or not. This imho makes a SHOULD a reasonable thing.

>> may not actually result in a peer seeing the given attribute. If
>> security context establishments, then the caller must inquire the
>> NAME for any CREDENTIAL HANDLE acquired with this NAME and then
>> check that the requested attribute has indeed been set in the
>> CREDENTIAL HANDLE's NAME."
>> 
> Nico --

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 10:15:22 -0600

> is known or not. This imho makes a SHOULD a reasonable thing.

Why is local configuration an appropriate thing to resort to here?
(And what else could it be but local configuration?  Do we really want
the mechglue and/or its providers to do network I/O in this one
function?)

Suppose we add an interactive credential acquisition function...  It
should suffice that the application and credential infrastructure
(e.g., KDCs) support a given attribute.  If using a new attribute then
requires distributing local configuration changes then we've made a
big mistake.

The more I think about it the more I want this paragraph to say
nothing about "unknown" attributes, and I really don't want it to say
"SHOULD return an error" in the case of unknown attributes.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 17 Nov 2011 18:29:42 +0100

On 11/17/2011 05:15 PM, Nico Williams wrote:
>>>> Expanding on my note from yesterday - here is suggested text
>>>> for section 7.6 (just after the list of error codes):
>>>> 
>>> mechglue could know if an attribute is "known" is by inquiring
>>> all its providers to see if it is.  Sure, the SPI could have a
>>> method to do the inquiry, but I'd not want to assume that.
>>> Besides, given that we agree that the caller that cares must
>>> check the acquired credential's name, I don't want to give
>>> developers a false sense that they don't have to.
>> 
>> The second MAY is pretty clear on that I think. A SHOULD says
>> that the mechglue is expected to do its best but that it MAY do
>> something else if it has good reason to. I suspect that most
>> implementations will have configuration to look at for
>> determining that an attribute is known or not. This imho makes a
>> SHOULD a reasonable thing.
> 
> (And what else could it be but local configuration?  Do we really
> want the mechglue and/or its providers to do network I/O in this
> one function?)
> 
> Suppose we add an interactive credential acquisition function...
> It should suffice that the application and credential
> infrastructure (e.g., KDCs) support a given attribute.  If using a
> new attribute then requires distributing local configuration
> changes then we've made a big mistake.
> 
> nothing about "unknown" attributes, and I really don't want it to
> say "SHOULD return an error" in the case of unknown attributes.

The way I see it is that (and I'm also trying to echo Sam who said
more or less the same thing) if you're trying to set a saml attribute
on a krb mechglue that doesn't do saml then it is a bit silly to get
a GSS_S_COMPLETE and have to go and read that attribute only then to
realize it wasn't set. That mech clearly "knows" that it can't set
a saml attribute, so why should it not return an error?

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 12:03:40 -0600

> a saml attribute, so why should it not return an error?

The only way the mechanism can do this for you is if a) the NAME
passed to this function is an MN, and b) the mechanism goes on to do
credential acquisition (talk to the KDC) under the covers if that's
the only way to find out whether the attribute is known.  If this is
what you and Sam have in mind then the I-D should say so (INTERNAL
NAME does not imply MN).

I agree that set-then-confirm is an obnoxious sequence of calls to
have to make, but I don't see why set-then-confirm should be OK for
handling criticality but not for handling known-ness if the latter
requires a round-trip trip to the KDC -- something that any potential
mechanism might, thus I don't see the distinction.

So, a few things:

 - If the name given to GSS_Set_name_attribute() is not an MN then I
think the function should not do anything with regards to whether the
attribute is known.  Yes, the mechglue could try to create an MN for
each {provider, mechanism}, and then get each provider to set the
given attribute on the resulting MNs.  But this seems like a lot of
work for a mechglue to do.

 - If the name is an MN, then there's still the question of whether
the mechanism will have to do network I/O in order to validate whether
the name attribute is known.  If so, then what credentials should the
mechanism use for such I/O?  In other words, I think we need a
credential argument here, much as we've discussed
GSS_Canonicalize_name_with_cred() in the past.

 - If the mechanism can validate name attributes, then it could handle
a critical flag.  Here, once again, we care about whether the
credential will include the attribute, so a credential input argument
seems in order.

Have we got this API all wrong?  I do think that we could use some
additional APIs for convenience, namely a function that takes care of
credential acquisition and name attribute setting (including
criticality) in one step.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 12:16:15 -0600

> work for a mechglue to do.

Also, the mechglue can't try all mechanisms when the given name is not
an MN.  The reason is that if some mechanisms fail to set the given
name attribute and some succeed, then what should the mechglue
return?!  We can't let any one mechanism that the application does not
need/care about prevent the app from using the given name attribute.
But we also don't know which mechanism the application cares about.

So if you want to avoid set-then-confirm for determining whether a
name attribute is known, then you must require that the input name be
an MN.  That still leaves the remaining issues open.

Here's my proposal:

 - either remove the text recommending failure for unknown name
attributes or require that the name be an MN in order for unknown
attributes to yield an error (but do allow the name to not be an MN --
I think that will be useful);

 - add (in this document or in a new I-D, your choice) a function that
combines the setting of name attributes with credential acquisition
(GSS_Acquire_cred_with_name_attributes()?).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Nov 2011 12:52:58 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> I think I want s/SHOULD/may/ here because the only way the
    Nico> mechglue could know if an attribute is "known" is by inquiring
    Nico> all its providers to see if it is.  

Unfortunately, I think I feel fairly strongly that this needs to be a
MUST not a SHOULD.
I agree that there are situations where you need to see if some external
system has permitted the attribute to be set.
In those situations you need to check the attribute is set.
However, there are a lot of cases--for example setting one of the
GSS-EAP attributes on a Kerberos MN, where you can determine it's not
going to work.
I think that it is important in the cases where the caller can catch the
error that we mandate it do so.
I feel quite strongly about this.

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Nov 2011 12:18:07 -0600

Why is this not an application-specific problem?  I.e., why should GSS
be solving this?

> I feel quite strongly about this.

But how would this be implemented if not with either local policy or
some protocol?  If local policy then that means local configuration
needs updating when you want to add new attributes.  Is that really
what you want?  I feel quite strongly that I don't want that.  If some
protocol, well, what's it look like?

You've also not answered my question: why is "known" different from
"critical"?   Why is one solution (check after cred acquisition) OK
for one (criticality) but not the other?

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Tue, 22 Nov 2011 23:21:17 +0100

On 11/22/2011 07:18 PM, Nico Williams wrote:
> Why is this not an application-specific problem?  I.e., why should
> GSS be solving this?
> 
> But how would this be implemented if not with either local policy
> or some protocol?  If local policy then that means local
> configuration needs updating when you want to add new attributes.
> Is that really what you want?  I feel quite strongly that I don't
> want that.  If some protocol, well, what's it look like?

Local config is *exactly* how this is handled in RP software today. For
instance Shibboleth require you to define your attributes in a config-
file.

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Nov 2011 16:23:27 -0600

> instance Shibboleth require you to define your attributes in a config-

But why must this be something the mechglue (or mechanism provider)
provides?  This seems very much application-specific, not generic.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Nov 2011 10:08:39 -0500

Is there any chance we could discuss this late this week (Thursday or
Friday)?

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Nov 2011 22:05:06 -0600

> Is there any chance we could discuss this late this week (Thursday or

Yes.  Ping me on either of those days.