Subject: [kitten] On SASL's authzid

From: Nico Williams <[email-masked]>
Date: Thu, 6 Mar 2014 20:05:39 -0600

Q: What is it?  It is:

My answer, as I understand it the authzid is:

 - an advisory, application-specific value sent by the client inside
the SASL mechanism's messages (i.e., protected by the mechanism, if
the mechanism can do it)

and

 - notionally it's the name of a resource (user account, mailbox, ...)
that the client wants to access or access things as.

Q: Why do we care about fitting things into the authzid?

My answer: because we don't want mechanisms to force new _required_
input elements on existing SASL APIs.

Someone please disabuse me of the above.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Thu, 6 Mar 2014 23:16:23 -0800 (PST)

If authzid is an advisory value for the user being authenticated and not the proxy then that fits nicely.  I'd happily define "user" in the spec as:

"Contains the user name being authenticated, the SASL authorization identifier 
(authzid).  The server MAY use this as a routing or database lookup hint.  The
server MUST NOT use this as authoritative, the user name MUST be obtained
from the OAuth credential."

If that works for you.

-bill

On Thursday, March 6, 2014 6:05 PM, Nico Williams <[email-masked]> wrote:
 
Q: What is it?  It is:

and

Nico
--

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Chris Newman <[email-masked]>
Date: Fri, 07 Mar 2014 12:52:47 +0000

> that the client wants to access or access things as.

SASL has two identities: "the user whose credentials are provided" 
(authentication id) and "the user to login/authenticate as" (authorization 
id). The former is in a namespace determined by the underlying identity 
system. Some mechanisms, like Kerberos, force a namespace on the identity 
system. Some mechanisms, like PLAIN, tend to work with a wide variety of 
identity systems. The authorization id is in a namespace determined by the 
application consuming SASL. Both of these identities are often user@host 
syntax in practice, but there are exceptions (e.g., LDAP DNs).

Two common scenarios for authorization identity are: using administrative 
credentials to login as another user, or a secretary using her credentials 
to login as her boss.

If the supplied credentials are not authorized to login as the 
authorization identity, that should result in a SASL failure (with an 
authorization failed error code if the enclosing protocol has one).

> input elements on existing SASL APIs.

I do not consider this an important design consideration, although it may 
be desirable to improve deployability of a mechanism. SASL's important 
function is a protocol design abstraction -- allowing an authentication 
mechanism suitable for multiple protocols to be encapsulated in multiple 
protocols without having to write how to do it separately for each one. 
Using a SASL API is completely optional and I've seen several cases where I 
consider SASL API usage harmful.

		- Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 7 Mar 2014 14:41:48 +0000

Maybe this is nitpicking, but:

> - an advisory,

This is not quite correct. Authentication engine needs to obey the specified value and can't just ignore it. Specific algorithm how an authenticated user is  authorised to act as an authzid is implementation and protocol specific.

> application-specific value sent by the client inside

This part is correct.

---

From: Bill Mills <[email-masked]>
Date: Fri, 7 Mar 2014 07:40:33 -0800 (PST)

So Alexey, 

Does this mran that if we specify "usrr" as the authn id in SASL that it must be used in protocol as the identity?   I don't really want to do that.

-bill

Sent from Yahoo Mail on Android

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 7 Mar 2014 15:57:22 +0000

On 3/7/14, 10:40 AM, "Bill Mills" <[email-masked]> wrote:

>So Alexey, 
>Does this mran that if we specify "usrr" as the authn id in SASL that it
>must be used in protocol as the identity? I don't really want to do that.

I think it would save time if somebody would just say what they *do* want
to do. Not in vague terms, and not using the word "hint", but an explicit
use case end to end, and then see if that is exactly what SASL authzid is
or isn't.

In the context of a mail client, I would guess the purpose of authzid is
to identify a mailbox to log into. Nothing more or less. If that's what
you want, it's authzid. If not, it's not, but then it also shouldn't be
something the client GUI has to supply based on user input, or an IMAP
server independent of SASL has to understand.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Mar 2014 10:32:44 -0600

> credentials to login as another user, or a secretary using her credentials

But there's a third one: name the IMAP mailbox you want to access.  In
the OAuth case, isn't that a "routing hint"?

> I do not consider this an important design consideration, although it may be
> desirable to improve deployability of a mechanism. SASL's important function
> is a protocol design abstraction -- allowing an authentication mechanism
> suitable for multiple protocols to be encapsulated in multiple protocols
> without having to write how to do it separately for each one. Using a SASL
> API is completely optional and I've seen several cases where I consider SASL
> API usage harmful.

Fair enough.  What about application UIs then?  If an IMAP application
uses SASL and has a field in a GUI for authzid, is it OK for it to
have to add a new field for a new mechanism?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Mar 2014 10:37:13 -0600

On Fri, Mar 7, 2014 at 8:41 AM, Alexey Melnikov
<[email-masked]> wrote:
> This is not quite correct. Authentication engine needs to obey the specified
> value and can't just ignore it. Specific algorithm how an authenticated user
> is  authorised to act as an authzid is implementation and protocol specific.

The authorization check could be synthetic though.  The authzid value
is only transported by the mechanism.  The app decides if the authcid
is permitted, and this decision can be very synthetic: use the authzid
to find something, then decide if the user has access.  For example,
in LDAP the authzid might be a DN, but as you know the rules for
matching some object by DN are not trivial, so the user may not
provide a canonical DN and everything might still work.  Indeed, the
server is free to decide that the access the user would have had w/o
an authzid is the same with any authzid -- nothing in RFC4422 forces
it to never so decide.

But maybe this isin't important.  The question I just asked Chris is
more important: is it OK for new mechanisms to impose new UIs/user
interactions on existing applications?

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Fri, 7 Mar 2014 11:51:48 -0800 (PST)

Yes, the mailbox you want to access is a good description.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Fri, 7 Mar 2014 20:13:58 +0000

> But maybe this isin't important.  The question I just asked Chris is more
> important: is it OK for new mechanisms to impose new UIs/user interactions
> on existing applications?

If this was software, you'd keep the API stable during minor revisions and rearrange things for major revisions. The UI would supply whatever it had to in order to use the version of SASL it wants to use.

Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Mar 2014 14:25:50 -0600

> If this was software, you'd keep the API stable during minor revisions and rearrange things for major revisions. The UI would supply whatever it had to in order to use the version of SASL it wants…

But SASL doesn't define an API (unlike GSS).  So we need to identify
what is to be kept stable, if anything, and it's not as simple as "the
API".

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Mar 2014 14:26:50 -0600

> Yes, the mailbox you want to access is a good description.

Then it's an authzid, no doubt in my mind.  Anyone disagree?

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Fri, 7 Mar 2014 20:52:00 +0000

> > If this was software, you'd keep the API stable during minor revisions and
> rearrange things for major revisions. The UI would supply whatever it had to
> in order to use the version of SASL it wants to use.
>
> But SASL doesn't define an API (unlike GSS).  So we need to identify what is
> to be kept stable, if anything, and it's not as simple as "the API".

In general, I would suggest that if a proposed change inspires compatibility concerns, it would seem to belong to the set of things you'd prefer to keep stable.

Bryce

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Mar 2014 15:58:31 -0600

> In general, I would suggest that if a proposed change inspires compatibility concerns, it would seem to belong to the set of things you'd prefer to keep stable.

I don't diagree.  However, since SASL doesn't have an "API" or
anything quite so well defined, so we don't quite know what the
intention was/is, if any, as to this sort of change.  We should state
what a mechanism can and cannot do.

I'm of the opinion that adding a required authzid-like item (like in
that the item is to be transported by the mechanism, but provided and
interpreted by the application) is a change to SASL, therefore not a
change that a mechanism may introduce.  Adding an _optional_
authzid-like item would be OK, but then we get to split hairs as to
what makes something optional or required: if not providing the
"optional" item means the mechanism won't work, then it sounds like
"required" to me, but if it's only the one mechanism that breaks, then
maybe we shouldn't care.

In any case, it does seem clear now that user= _is_ the same as
authzid.  So we don't have to spend any more effort thinking about the
above (though arguably we should).

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 7 Mar 2014 22:06:55 +0000

>above (though arguably we should).

It's been clear to some people at times, but I have yet to hear real
confirmation from the people with the use case as to whether that's true
as a whole, or as to whether *some* of the use cases for the user hint
align but others don't.

I'm only saying this because I'm on the list and I fear another long round
of hashing and thrashing to get back to the same unclear endpoint. If I'm
tired of it, I can't imagine how the principals are.

-- Scott

---

From: Bill Mills <[email-masked]>
Date: Fri, 7 Mar 2014 14:13:36 -0800 (PST)

So can we say that the value in "user" must agree with the user asserted by the token?

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 7 Mar 2014 22:19:10 +0000

>So can we say that the value in "user" must agree with the user asserted

That depends on what "agree" means. It's a policy issue.

The athzid is the *asserted* identity to login as, which is NOT always
what's in the token. The token is who's logging in, the authzid is who
you're logging in *as* for that transaction.

If by agree you mean "is authorized to act as", then yes. But that's
entirely application layer business, nothing to do with the mechanism.

-- Scott

---

From: Bill Mills <[email-masked]>
Date: Fri, 7 Mar 2014 14:22:02 -0800 (PST)

Then user isn't autzid it's authcid.

---

From: Ryan Troll <[email-masked]>
Date: Mon, 10 Mar 2014 10:21:34 -0700

Google uses the user= field as an authzid.  It identifies the mailbox being
accessed, and the session terminates at the server responsible for that
mailbox.

In the future, if a client provided users with the ability to log in as
user A and read mailbox B, we would want to know identity B.  Which
certainly appears to be the authzid.

Scott - does this help?

-R
On Mar 7, 2014 2:22 PM, "Bill Mills" <[email-masked]> wrote:

> Sent from Yahoo Mail on Android<http://overview.mail.yahoo.com/mobile/?.src=Android>
>
>  ------------------------------
> * From: * Cantor, Scott <[email-masked]>;
> * To: * Bill Mills <[email-masked]>; Nico Williams <
> [email-masked]>; Nordgren, Bryce L -FS <[email-masked]>;
> * Cc: * [email-masked] <[email-masked]>;
> * Subject: * Re: [kitten] On SASL's authzid
> * Sent: * Fri, Mar 7, 2014 10:19:10 PM
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Mar 2014 17:26:44 +0000

On 3/10/14, 1:21 PM, "Ryan Troll" <[email-masked]> wrote:

>Google uses the user= field as an authzid.  It identifies the mailbox
>being accessed, and the session terminates at the server responsible for
>that mailbox.

It helps me, in the sense that both those use cases seem pretty clearly
exactly what authzid is. They have literally nothing to do with OAuth or
this mechanism, and would apply to any mechanism Google supported.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Mar 2014 12:48:34 -0500

> this mechanism, and would apply to any mechanism Google supported.

Agreed.  I think it's settled: user= is an authzid.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 10:56:17 -0700

And so it goes in a= in the GS2 header?

-bill

--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!

On Monday, March 10, 2014 10:49 AM, Nico Williams <[email-masked]> wrote:

Nico

--

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Mar 2014 18:03:37 +0000

>And so it goes in a= in the GS2 header?

If the plan is to maintain the GS2 framing (I lost track of that), then
it's not clear anything has to be said at all, since that's basically
defined by GS2 and is independent of whatever mechanism is using GS2. If
it's a SASL concept, it's a SASL concept, it doesn't have to be noted in
every mechanism unless there's something special to say about it, and I
don't think there is. Less is more. That's just my take.

But yeah, if you want to say something about it...

-- Scott

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 11:14:28 -0700

So we can leave it in user= and not define any GS2 header stuff beyond making sure the parsers handle it in the SASL side? 

I got the impression from Sam that there's a case where a SASL mechanism talks to a GS2 server and it just works.  This sounded like it means that the authzid should be populated into the S2 header.

-bill

On Monday, March 10, 2014 11:04 AM, "Cantor, Scott" <[email-masked]> wrote:

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 10 Mar 2014 18:22:07 +0000

On 3/10/14, 2:14 PM, "Bill Mills" <[email-masked]> wrote:
>
>So we can leave it in user= and not define any GS2 header stuff beyond
>making sure the parsers handle it in the SASL side?

No, I'm saying you leave it out and let GS2 handle it, because it already
is.

>I got the impression from Sam that there's a case where a SASL mechanism
>talks to a GS2 server and it just works.  This sounded like it means that
>the authzid should be populated into the S2 header.

Yes. But that means you need to say nothing about it, unless I'm missing
something. You simply define in terms of GS2, so anything GS2 allows or
requires is there by definition.

That all assumes there's still a refernce to GS2 planned here. If that's
being tabled due to the lack of mutual-auth, and you're defining
essentially a GS2-like header that is compatible with it but not formally
GS2, then you would have to define it in this spec.

-- Scott

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 11:26:07 -0700

My intent is to only do enough here to make sure that GS2 interop can work in the future since there are folks that care.

-bill

On Monday, March 10, 2014 11:23 AM, "Cantor, Scott" <[email-masked]> wrote:

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Mar 2014 19:52:59 -0500

We now agree that user= is just the authzid.  Good.

The only question is whether to describe user= at all.  Assuming that
you need it for interop with Google you have two choices:

 - don't use GS2

 - use GS2 and shoe-horn in the user= as a name attribute at the GSS
layer (or leave it for GSS implementors to figure that out?)

Either works.  I submitted an I-D last week for adding a GSS name
attribute for conveying authzids, so it just so happens that it should
be easy enough to do what you want.  Let's see if we can.  What does a
fully formed SASL OAuth token's "header" with user= look like?

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 17:58:57 -0700 (PDT)

Examples in http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14#section-4

Does that answer your question?

On Monday, March 10, 2014 5:53 PM, Nico Williams <[email-masked]> wrote:

- don't use GS2

Nico

--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Mar 2014 20:14:13 -0500

On Mon, Mar 10, 2014 at 7:58 PM, Bill Mills <[email-masked]> wrote:
> Examples in
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14#section-4
>

Yes!

You have two options that are equivalent, and you need only choose
whether you want to describe a GSS mechanism that can be used as a GS2
mechanism, or a SASL mechanism from which one could derive a GSS
mechanism that interops with the SASL one when used in a GS2
framework.

In the first case all you have to say is that the tokens start with
the GS2 header, and that if there's an authzid it will appear twice,
once in the a= attribute in the GS2 header, and once in a user=
attribute past the GS2 header.

In the second case you'd say that the OAuth GSS mechanism's
GSS_Init_sec_context() outputs a token as it would look without the
GS2 header, and that if the initiator name had an authzid set then
this is sent as user=<authzid>.  Then automatically when this
mechanism is used in SASL via GS2 SASL will add the a=<authzid>, and
if the GS2 implementation knows to set the GSS authzid attribute then
it will also appear as user=<authzid>.

If you do the latter you'll need to reference:

http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00

The obvious choice is the first: it's easier on you.  It's pretty much
what we did with SCRAM, with just a smidgen of text saying GSS-related
things for anyone who wanted to implement SCRAM as a GSS mechanism
used in a SASL GS2 framework.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 18:18:43 -0700 (PDT)

Option #1 is almost where we are now.  Just need to steal your second paragraph above and explain the potential duplicate authzid if a GS2 mechanism is defined.

On Monday, March 10, 2014 6:14 PM, Nico Williams <[email-masked]> wrote:

Yes!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 10 Mar 2014 20:36:46 -0500

On Mon, Mar 10, 2014 at 8:18 PM, Bill Mills <[email-masked]> wrote:
> Option #1 is almost where we are now.  Just need to steal your second
> paragraph above and explain the potential duplicate authzid if a GS2
> mechanism is defined.

You want to say that if an authzid is set then it's sent in both, a=
and user=.  That's because otherwise you'd not have a mechanism that
could be conceived as a GS2 mechanism or you'd not interop with
Google.

A little duplication will have to be accepted if you want both, a
GS2-interoperable and Google-interoperable mechanism.  It's the
consequence of not having noticed and fixed this at Google long ago.
I think that's fine.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 10 Mar 2014 18:52:36 -0700 (PDT)

OK, so here's proposed new text for defining user=

"Contains the user name being asociated with the
resource being accessed, the SASL "authzid".  If a GS2
mechanism is defined this value will be duplicated unless
the GS2 mechanism is defined so this value can be re-used."

On Monday, March 10, 2014 6:36 PM, Nico Williams <[email-masked]> wrote:

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 16:50:59 -0500

> the GS2 mechanism is defined so this value can be re-used."

How about replacing the last sentence with: "In order to interoperate
with GS2 implementations of this same mechanism the user= SHOULD also
appear in the GS2 header's authzid attribute (a=)."

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Tue, 11 Mar 2014 15:06:57 -0700 (PDT)

I was being more vague because you (?) mentioned the renaming stuff.  I'm happy to use that text.

"Contains the user name asociated with the resource being accessed, the 
SASL "authzid".  In order to interoperate with GS2 implementations of 
this same mechanism the user= SHOULD also appear in the GS2 header's 
authzid attribute (a=)."

Any objections?

On Tuesday, March 11, 2014 2:51 PM, Nico Williams <[email-masked]> wrote:

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 17:51:55 -0500

> I was being more vague because you (?) mentioned the renaming stuff.  I'm

Ah, I thought you were being vague because you didn't want to REQUIRE
the duplication.

I would prefer to REQUIRE that the authzid go in the GS2 a= and in the
user=.  That gets us both: interop with Google and interop with GS2.

(But I can bend on this because I'm intent on adding an authzid option
to GSS (as a name attribute) so that in the end a GS2 implementation
that supported that option could live with just the user= bit.)

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Tue, 11 Mar 2014 17:15:00 -0700

Can we leave a= to when a GS2 mechanism is defined?  or do we need it in now so the SASL mechanism is forward compatible?

-bill

On Tuesday, March 11, 2014 3:52 PM, Nico Williams <[email-masked]> wrote:

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 19:58:31 -0500

On Tue, Mar 11, 2014 at 7:15 PM, Bill Mills <[email-masked]> wrote:
> Can we leave a= to when a GS2 mechanism is defined?  or do we need it in now
> so the SASL mechanism is forward compatible?

If you want implementations made now to be interoperable with future
GS2 implementations, then it'd have to be now... unless we also agreed
to update GS2 to take into account the notion of GSS authzid naming
attribute that Viktor presented last week.  I'll ask separately about
the update to GS2.

---

From: Ryan Troll <[email-masked]>
Date: Tue, 11 Mar 2014 20:09:23 -0700

Once this is published, Google will be making changes in order to conform
to the RFC.  This should require two specific changes:

   - Support for the appropriate mechanism name
   - Update to use (whatever user= becomes)

In other words, we will use whatever authzid attribute name you guys decide
on - it doesn't have to be "user=" just because we said so.  If you'd
prefer to name it something else, go for it - don't stick with "user=" for
Google interop.

-R

---

From: Bill Mills <[email-masked]>
Date: Tue, 11 Mar 2014 20:17:42 -0700 (PDT)

Nico, confirming it's OK if we make the "a=" authzid mandatory?

On Tuesday, March 11, 2014 8:09 PM, Ryan Troll <[email-masked]> wrote:
 
Once this is published, Google will be making changes in order to conform to the RFC.  This should require two specific changes:
	* Support for the appropriate mechanism name
	* Update to use (whatever user= becomes)
In other words, we will use whatever authzid attribute name you guys decide on - it doesn't have to be "user=" just because we said so.  If you'd prefer to name it something else, go for it - don't stick with "user=" for Google interop.

-R

On Tue, Mar 11, 2014 at 3:51 PM, Nico Williams <[email-masked]> wrote:

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Mar 2014 22:42:20 -0500

On Tue, Mar 11, 2014 at 10:17 PM, Bill Mills <[email-masked]> wrote:
> > Once this is published, Google will be making changes in order to conform to
> > the RFC.  This should require two specific changes:
> >
> >  o Support for the appropriate mechanism name
> >  o Update to use (whatever user= becomes)
> >
> > on - it doesn't have to be "user=" just because we said so.  If you'd prefer
> > to name it something else, go for it - don't stick with "user=" for Google
> > interop.

Perfect.

> Nico, confirming it's OK if we make the "a=" authzid mandatory?

Yes.

Nico
--

---

From: "Alexey\ Melnikov" <[email-masked]>
Date: Wed, 12 Mar 2014 10:28:57 +0000

>Can we leave a= to when a GS2 mechanism is defined?  or do we need it in now so the SASL mechanism is forward compatible?

I would prefer not to have any new SASL mechanisms that don't support authorization identities (a= in this case).
So yes, we need it now.

-bill

 

Nico
--