Subject: Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05

From: Simon Josefsson <[email-masked]>
Date: Mon, 03 Sep 2012 10:18:45 +0200

William Mills <[email-masked]> writes:

> Draft -06 is posted.  Ir removes the user field, adds canonicalization
> language, and once again fixes the examples to be current.

Thanks!  Below I quote a few sections and give some comments.  I may
have missed some recent emails in this thread, but here I try to focus
on what is in the document rather than what may have been
discussed/agreed out-of-band.

3.  OAuth SASL Mechanism Specifications
...
   In the case where authorization fails the server sends an error
   result, then client MUST then send an additional message to the
   server in order to allow the server to finish the exchange.  Some
   protocols and common SASL implementations do not support both sending
   a SASL message and finalizing a SASL negotiation, the additional
   client message in the error case deals with this problem.  This
   exchange is:

This is the old text that I suggested a rewrite of in:
http://thread.gmane.org/gmane.ietf.sasl/5935 It looks as if you
acknowledged that, but the old text remains.  I see that you added
section 3.2.4, so maybe you could just remove some details here?

Further, the example following the text above (and elsewhere in the
document) is incorrect when it says "empty" since section 3.2.4 says the
message contains %x01.  Either make the message purely empty or use a
term like "dummy message" instead of "empty message".

3.1.  Initial Client Response

   [...] The client MUST send an authorization ID in the gs2-header.

Is this MUST intentional?  Normally authorization identities are not
asserted in SASL so this would be unusual.  I would remove this
sentence.

3.1.2

   o  The "gs2-authzid" carries the authorization identity as specified
      in [RFC5801].  This MUST agree with the identity asserted in the
      OAuth credential.

This also seems unusual -- why can't the authorization identity be
orthogonal to the OAuth identity?  I believe it has been suggested
several times to say as little as possible about the authorization
identity in this document, and I believe that continues to be a good
advice.  The semantics of SASL authorization identities follow from RFC
4422 and you would only need serious discussion of it when you are not
following RFC 4422 recommendations.

3.2.1.  Mapping to SASL Identities

   Some OAuth mechanisms can provide both an authorization identity and
   an authentication identity.  An example of this is OAuth 1.0a
   [RFC5849] where the consumer key (oauth_consumer_key) identifies the
   entity using the token which equates to the SASL authentication
   identity, and is authenticated using the shared secret.  The server
   MAY use a consumer key, a value derived from it, or other comparable
   identity in the OAuth authorization scheme to allow SASL an
   authentication identity different from the authorization identity to
   be set.

The OAuth 1.0a example in the second sentence seems to be missing
something: it describes how OAuth 1.0a provide an authentication
identity, but it does not describe how OAuth 1.0a provides for an
authorization identity as far as I can tell?  Adding a sentence after
the second, that describe how OAuth 1.0a provides an authorization
identity would help, and may help me understand the last sentence which
I can't understand the meaning of right now.

5.2.  OAuth 1.0a Authorization with Channel Binding
...
   y,a=[email-masked]^A
...

This uses a gs2-header cb-type of 'y' -- this seems wrong.  If channel
bindings are used (which is indicated by clients and servers having the
OAUTH10A-PLUS mechanism type available), the cb-type should be 'p' and
the cb type identifier should be present.  Recall the meaning of "y"
from RFC 5801:

                      ;; "y" -> client supports CB, thinks the server
                      ;;           does not

This only happens when the server does not advertise the *-PLUS
mechanism.

/Simon

---

From: William Mills <[email-masked]>
Date: Mon, 3 Sep 2012 15:08:28 -0700 (PDT)

Comments inline below, thanks for the review.

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Luke Howard <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, September 3, 2012 1:18 AM
>Subject: Re: -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
> 

I'll change it to "dummy message".  Works for me.

>asserted in SASL so this would be unusual.  I would remove this

Yes, because we want to have the plain text username available.

>I can't understand the meaning of right now.
The last sentence of 3.2 above 3.2.1 is "The authorization scheme MUST 
carry the user ID to be used as the authorization identity (identity to 
act as). The server MUST use the ID obtained from the credential as the 
user being authorized."

Should that sentence move into 3.2.1?

>the cb type identifier should be present.  Recall the meaning of "y"

I *KNEW* I had to have gotten something wrong in CB.  Will fix that.

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Sep 2012 17:32:10 -0500

> Yes, because we want to have the plain text username available.

Ryan wants it, yes, but SASL makes it strictly OPTIONAL, which means
that it must be optional here as well.

(Ryan has already indicated that he understands that this means that
he must reject connections/authentications from clients that a) do not
provide an authz-id, and b) from whose authcid his software cannot
derive a suitable authz-id.)

(There is no subtext here.  The semantics of SASL cannot be changed by
a SASL mechanism.  That's a hard constraint on your mechanism.  Note
too that this has nothing to do with gs2 -- we're dealing with SASL
semantics, not GSS semantics, so RFC4422 applies.)

>>following RFC 4422 recommendations.

Indeed, it is not correct to say that the authz-id must agree the
authcid.  The two concepts have radically different semantics.

William, I *strongly* suggest that you just say *nothing* about what
the authz-id must be.  Indeed, it's not a suggestion.  You must say
nothing about the authz-id's form here, for that is not the
mechanism's place.  The authz-id namespace and meaning is defined by
the application protocol, not the mechanism.

>>3.2.1.  Mapping to SASL Identities

You probably mean mapping from authcid to authz-id.  This too you
cannot say anything about (see above).

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Sep 2012 09:20:24 +0200

> Yes, because we want to have the plain text username available.

The SASL framework doesn't have any concept of usernames, so if you want
to transfer a "username" from the client to the server you need a
separate field for that in the mechanism.  SCRAM does this, so that is
an acceptable route.  However, I'm not certain you actually mean
"username" here.  Maybe you really mean authorization identity?  Or do
you mean the authentication identity?  Sometimes usernames and
authentication identities are used interchangeable but I'm not certain
this is the case here.

The SASL framework says the authzid is optional and that it is asserted
by the client application.  It shouldn't be used for something mechanism
internal.

I'll see if I can re-read Ryan's motivation for the username field.  I'm
thinking that perhaps he is really after an authzid field, and if the
authzid field is not present, he has to guess which authorization
identity is intended (or fail if he cannot guess).  I believe this usage
would be in line with the SASL model, although would require some user
training because users normally doesn't specify an authzid.  That's fine
though.  This approach is consistent with the protocol syntax in -06,
but the text describing how the syntax should be used is a bit off
currently.  So I don't think you actually want a username field, just
fix some text.

> Should that sentence move into 3.2.1?

I must admit that the sentence doesn't make sense to me.

The (SASL) authorization identity should be transferred from client to
server without modification (modulo character set encodings).  It is
asserted by the client and consumed by the server.  Usually it is not
related to the credential type at all.

Thus, saying that another field in the credential MUST be used as the
SASL authorization identity seems quite far from how the SASL framework
is designed.  I don't see why you would design it this way -- it seems
overly complex for no gain that I have understood so far.

Hmm.  Perhaps at this point it would be more productive if one of us
usual GSSAPI/SASL suspects modify your draft into something that makes
sense in the GSSAPI/SASL model and then you can check if it works for
you in the OAuth world?

> I *KNEW* I had to have gotten something wrong in CB.  Will fix that.

Great.  I suggest to use the 'tls-unique' channel binding type, it is
what SCRAM and GS2 prefers, with a fallback to 'tls-server-end-point'.
Compare section 6.1 of RFC 5802.  You probably need a similar section in
this document.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 04 Sep 2012 09:51:41 +0200

Simon Josefsson <[email-masked]> writes:

> I'll see if I can re-read Ryan's motivation for the username field.

Having re-read some emails, I believe Ryan really wants the usual SASL
authcid/authzid semantics.  It should be similar to how PLAIN or SCRAM
works today.  Please correct me below if this is wrong.  The
requirements as I understand them are:

1) The server must know the IMAP/SMTP/etc user.  This is the
authorization identity, authzid.  Normally in SASL the authzid is not
present, but implied from the authentication identity.  Since authzid's
are often absent, it becomes important for the server to know the
authcid, because the server has to infer the authzid from the authcid
when the authzid is not specified.

that creates another requirement:

2) The server must know the identity of the OAuth bearer token owner.
This is the authentication identity (authcid).  This must be available
to the server.  It doesn't have to be sent by the mechanism though (see
below).

Right now I don't believe -06 describes how the server knows the
authentication identity and that is the issue.

I think there are two design options:

1) The server finds the authcid by using the OAuth bearer token as a key
in some table to find out who owns that particular token.  This may not
be practical in all OAuth implementations.  (Of course, it should work
for all OAuth schemes not just bearer tokens.)

2) The client must provide the OAuth credential owner in another field,
i.e., the infamous "user"-field.  The server verifies the bearer token
using that user field.  The next step is to find the IMAP/SMTP user,
which follows the usual SASL pattern.

There is complexity in that OAuth credentials can be issued from a user
X to someone else Y and that Y can then effectively impersonate X (until
revoked by X).  However I don't think this complexity matters for the
SASL/GSSAPI mechanism.  Whether the SASL client endpoint is X or Y is
outside the scope of the SASL model, the logical SASL client endpoint
from SASL's point of view is X.  Arguable, the information about Y can
be useful to servers, and maybe GSS-API naming attributes can be used
here, however it is not strictly needed as I see it.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 08:32:01 -0700 (PDT)

I've been having a side conversation with Nico.  The MUST that used to be there on authzid is removed.  Servers like Ryan's use case can put in their service docs that authzid is required, and it will become the de facto usage standard for things like IMAP even if we don't write that into the doc.

We're also word-smithing the identity mapping language.

The current draft, in the paragraph before 3.2.1, states that the authzid is derived from the auth token.  Is that not clear enough?  3.2.1 is intended to describe how to get authcid when there is one available.  For all practical purposes a desktop client does not have a useful authcid, it's the equivalent of a user agent string if present.  Authcid can be determined from the token or the client id in 3 party cases.

-bill

>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 4, 2012 12:51 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 15:38:39 +0000

On 9/4/12 11:32 AM, "William Mills" <[email-masked]> wrote:

>The current draft, in the paragraph before 3.2.1, states that the authzid
>is derived from the auth token.  Is that not clear enough?

It's wrong. The authzid is evaluated together with the identity
information from the mechanism, but it's not "derived from" it.

None of this has any connection to the OAuth token's internal notions of
delegation of access. That just adds a second layer of indirection that
the mechanism will have to accommodate or expose as Simon noted.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 08:58:22 -0700 (PDT)

Tell me how this works when the client sends no authz-id and is authenticating with a Bearer token.  SASL needs in the end to have a user identity, where does that come from?

Based on the answer above, what language is correct to say that the identity comes out of the token?

Thanks,

-bill

> From: "Cantor, Scott" <[email-masked]>
>To: William Mills <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Tuesday, September 4, 2012 8:38 AM
>Subject: Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
>

---

From: Ryan Troll <[email-masked]>
Date: Tue, 4 Sep 2012 09:07:31 -0700

On Tue, Sep 4, 2012 at 8:32 AM, William Mills <[email-masked]> wrote:

> I've been having a side conversation with Nico.  The MUST that used to be
> there on authzid is removed.  Servers like Ryan's use case can put in their
> service docs that authzid is required, and it will become the de facto
> usage standard for things like IMAP even if we don't write that into the
> doc.
>

This works for me.  The spec adheres to the approach defined by SASL, and
I'll use a method of determining the user that's likely to be the same as
other services attempting to do the same.

-R

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 16:32:56 +0000

On 9/4/12 11:58 AM, "William Mills" <[email-masked]> wrote:
>
>Tell me how this works when the client sends no authz-id and is
>authenticating with a Bearer token.  SASL needs in the end to have a user
>identity, where does that come from?

The Bearer token, presumably. The GSS portion of your mech establishes a
"name" for the identity of the initiator (the client). That name is then,
I believe, surfaced in the SASL layer as the authenticated identity.

>identity comes out of the token?

The authentication identity definitely comes from the token; I was
reacting to the statement that the SASL authz-id did.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 09:40:33 -0700 (PDT)

Ah! I'm missusing the term authz-id then.  So what's the right language then for stating that the identity derived form the token is authoritative and is what is used?  

>Sent: Tuesday, September 4, 2012 9:32 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 16:59:03 +0000

On 9/4/12 12:40 PM, "William Mills" <[email-masked]> wrote:

>Ah! I'm missusing the term authz-id then.  So what's the right language
>then for stating that the identity derived form the token is
>authoritative and is what is used?

Used by what?

I don't know what SASL's term of art is for the authenticated identity
(I've spent more time at the GSS layer) but because your mechanism is
actually a GSS mech, I would say that you need language along the lines of
what's in mine (or I'll need different language myself).

Section 5.4 of 
http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-ec-02 has my latest
text for this.

OAuth and SAML are not materially different. They both have to address
that the identity of the user as typed in has zero to do with either the
identity of the user at the actual IdP, the identity of the user in an
issued token, or the identity of the user at the RP. Those are three
different notions because of how federated identity works.

The SASL authz-id concept addresses the latter. The rest is going to be
something clients and mechanism implementations will have to deal with.
Given a typical client, the user is entering "something" they're told to
enter. That has to lead to appropriate behavior in the rest of the pieces
based on policy at each point. For example, it could key into an identity
"store" that selects the underlying credential to talk to the IdP with.

So in my view, what's being entered is the authz-id. "Magic happens" to
derive the right username to use when authenticating to the token issuer.
And then the token includes some identifier that is based on how the token
issuer is setup. And then the mechanism surfaces an authenticated identity
(in GSS it's the initiator name) based on the token. And then policy kicks
in to determine if that name can access the service, or access the service
as the authz-id.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 10:14:30 -0700 (PDT)

If I read your text right then basically you're leaving it completely to the implementer to magically use the info they have to provide the GSS_C_NT_USER_NAME?  You're just saying ot have to provide it and give no guidance for how it's related to the credentials at all?

>Sent: Tuesday, September 4, 2012 9:59 AM

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Sep 2012 10:56:47 -0700

> different notions because of how federated identity works.

And not even just federated identity, but identity period, which is why
SASL has had the separation between the authentication identity and the
authorization identity even before federated identity became common.
Separating authentication and authorization identity allows for delegation
and proxying, where I (for example) authenticate to the IMAP server as
myself (authentication identity) but say that I want to read the folders
for some other user (authorization identity).

RFC 2222:

   The transmitted authorization identity may be different than the
   identity in the client's authentication credentials.  This permits
   agents such as proxy servers to authenticate using their own
   credentials, yet request the access privileges of the identity for
   which they are proxying.  With any mechanism, transmitting an
   authorization identity of the empty string directs the server to
   derive an authorization identity from the client's authentication
   credentials.

> derive the right username to use when authenticating to the token
> issuer.  And then the token includes some identifier that is based on
> how the token issuer is setup. And then the mechanism surfaces an
> authenticated identity (in GSS it's the initiator name) based on the
> token. And then policy kicks in to determine if that name can access the
> service, or access the service as the authz-id.

Yes, that sounds right to me as well.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 18:19:03 +0000

On 9/4/12 1:14 PM, "William Mills" <[email-masked]> wrote:
>
>If I read your text right then basically you're leaving it completely to
>the implementer to magically use the info they have to provide the
>GSS_C_NT_USER_NAME?

Well, that text is there because most apps using this infrastructure seem
to more or less assume that's what they can use. Some of that is just
historical I think, but it remains true. I'm still being guided on that by
Simon and by somebody who's implementing my spec with ssh as a prototype.

The implementer has to make sure that name form works or apps just won't
work with the new mechanism. As far as what to do with it, the "magic"
part is the separation between the client/server communication and what's
going on between the client and the IdP and in the token. That's not
exactly "magic" but it's not specified either because it isn't possible to
specify it without breaking real world use of the technology (in my case
SAML, in your case OAuth).

>You're just saying ot have to provide it and give no guidance for how
>it's related to the credentials at all?

The mechanism if it's doing its job is making sure that any identity it
reports to the mechglue (that's the layer between GSS-API libraries and
mechanisms) is "supportable" by the credentials. In a bearer token case,
it means the token is valid as presented, etc.

I probably left that implicit, and it probably doesn't have to be. But you
have to take some care to be clear that it's just that internal identity
you're talking about. It's essentially saying "the authenticated identity
reported by the mechanism is the identity which the mechanism has securely
established for the client". Sort of common sense.

But what you can't do is step into application land or step on the
authz-id in SASL, which has no direct relationship to that identity.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 18:25:31 +0000

>for some other user (authorization identity).

That's certainly true, but with federation, the problems of naming
uniformity (the lack thereof) become bigger, and it's practically a given
that even when you aren't doing any delegation of authority the names on
each side won't line up.

I guess SASL's authz-id notion can be used to help with that. It's a
serious issue with GSS that I think ends up needing name attributes and/or
local mappings to deal with at this point. I believe even with Kerberos it
is/was to some extent handled by mappings, but Kerberos at least has the
simple, familiar, and Unix-like naming scheme for principals. OAuth and
SAML do not (flexible, but also a pain to deal with).

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 11:32:13 -0700 (PDT)

I really like the turn of phrase you use, "the authenticated identity
reported by the mechanism is the identity which the mechanism has securely
established for the client".  It says exactly what I want to say.  Would this
pass muster in place of my mistaken usage of authz-id?

-bill

>Sent: Tuesday, September 4, 2012 11:19 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 18:36:09 +0000

>pass muster in place of my mistaken usage of authz-id?

It's ok by me (obviously).

-- Scott

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Sep 2012 11:40:29 -0700

William Mills <[email-masked]> writes:

> reported by the mechanism is the identity which the mechanism has
> securely established for the client".  It says exactly what I want to
> say.  Would this pass muster in place of my mistaken usage of authz-id?

Yup, that seems fine to me.

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:02:19 -0500

> reacting to the statement that the SASL authz-id did.

The ID authenticated by the mechanism is the authcid.

That has to (necessarily) come from the OAuth token, or else be
implied by something in it.

The authz-id is just an application-level concept that the mechanism
transports without interpretation or modification.  (Nor can the
mechanism map an authcid to an authz-id).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:04:13 -0500

On Tue, Sep 4, 2012 at 12:14 PM, William Mills <[email-masked]> wrote:
> If I read your text right then basically you're leaving it completely to the
> implementer to magically use the info they have to provide the
> GSS_C_NT_USER_NAME?  You're just saying ot have to provide it and give no
> guidance for how it's related to the credentials at all?

GSS_Accept_sec_context() outputs the NAME of the initiator.  This
corresponds to the SASL authcid -- the ID authenticated by the
mechanism.

The constant "GSS_C_NT_USER_NAME" is a red herring here :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:08:48 -0500

> pass muster in place of my mistaken usage of authz-id?

Yes, but post actual text?

Whatever ID OAuth authenticates, that's the authcid.

The OAuth *core* has absolutely nothing to do with the authz-id,
nothing.  The gs2-header transports the authz-id from the client app
to the server app, and prepending the gs2-header to the CB data
provides integrity protection to the authz-id (and other things in the
gs2-header).  Thus the SASL/GS2 OAuth mechanism, like any other SASL
mechanism, provides for transportation of the authz-id, and it
provides integrity protection as one would expect of any mechanism
that can provide real security (as compared to PLAIN).

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 20:13:00 +0000

>The constant "GSS_C_NT_USER_NAME" is a red herring here :)

I was told it's not really a red herring, because there are lots of GSS
apps that just flat won't work unless the name's in that form from the
mechanism, or at least translatable into it I suppose.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 13:19:55 -0700 (PDT)

> From: Nico Williams <[email-masked]>
>Cc: "Cantor, Scott" <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 4, 2012 1:08 PM

OAuth can provide both the user identity and the identity of the agent
using the ctredential.  I don't think you want 2 values for authcid.

>that can provide real security (as compared to PLAIN).

An OAuth mechanism can validate that the autz-id sent is correct, and
in fact if the wrong agent presents a credential it SHOULD fail if that
credential was issued for a specific agent/proxy.

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 20:30:15 +0000

>using the ctredential.  I don't think you want 2 values for authcid.

No, but you have to pick one, and then make the other available if you
choose to via GSS. There is no way to do that via SASL itself, I don't
think.

>credential was issued for a specific agent/proxy.

No, you can't. Your mechanism will NOT know the authz-id because it's a
GSS mechanism and the SASL part is stripped off. That's what we've been
trying to explain. It is not your mech's job to do that anaylsis and
rejection, it's the application's job. You don't need to say this, it's
covered by SASL.

You are conflating OAuth's notion of multiple identities with the
authz-id. You can't do that. OAuth's notions have nothing to do with
SASL's. In effect, there are three in play here, authz-id, and two OAuth
notions that you have to collapse into an authcid for SASL.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 13:37:38 -0700 (PDT)

Proposed text as requested.  Starting with the last paragraph in -06 before 3.2.1 the text WAS:

    The server responds to a successfully verified client message by 
completing
    the SASL negotiation. The authorization scheme MUST carry the user ID to be
    used as the  authorization identity (identity to act as). The server MUST 

    use the ID obtained from the credential as the user 
being authorized. 

    Some OAuth mechanisms can provide both an authorization identity and an   

    authentication identity.  An example of this is OAuth 1.0a [RFC5849] 
where  

    the consumer key (oauth_consumer_key) identifies the entity using the token 

    which equates to the  SASL authentication identity, and is 
authenticated using 

    the shared secret.   The server MAY use a consumer 
key, a value  derived from 

    it, or other comparable identity in the OAuth authorization scheme  to allow 

    SASL an authentication identity 
different from the authorization identity to 

    be set. 

The proposed new text IS:

    The server responds to a 
successfully verified client message by completing 

    the SASL negotiation. The authenticated identity reported by the mechanism
    is the identity 
which the mechanism has securely established for the client 

    with the 
OAuth credential.

    Note that the semantics of the authz-id are specified by the SASL 
framework 
    [RFC4422]. A SASL application is, of course, free to apply 
mappings of the 
    OAuth authcid to authz-ids as per-SASL, and it is free 
to apply mappings common 
    to non-SASL OAuth applications. For example a 
developer implementing an OAuth 
    1.0a [RFC5849] mechanism where the 
consumer key (oauth_consumer_key) identifies 
    the entity using the token and the token itself identifies the user
the developer 
    could map these to the SASL authz-id and authcid.

----- Original Message -----
>>  established for the client".  It says exactly what I want to say.  
> Would
>>  this

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:40:07 -0500

> using the ctredential.  I don't think you want 2 values for authcid.

This is why I suggested earlier that you report a combination of the
two as the authcid.  However, a better suggestion is provided below
based on GSS naming extensions.

> credential was issued for a specific agent/proxy.

NO.  The OAuth mechanism CANNOT INTERPRET OR MODIFY OR PROVIDE an authz-id.

Given that you have *two* IDs to report in the authcid vein, where
SASL only allows *one*, we have what appears to be a fundamental
incompatibility between OAuth and SASL.  We *can* address this as
follows:

 - make one of the user or agent IDs the authcid

 - treat the other of those two IDs as a GSS name attribute

It's perfectly fine to extend existing SASL APIs to provide the second
ID in some way other than by exposing a GSS NAME object to the
application.

The question is: which ID is best to report as the authcid: the user,
or the agent ID?

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 13:42:18 -0700 (PDT)

> trying to explain. It is not your mech's job to do that anaylsis and

You're directly contradicting what others have said I think? 

----- Original Message -----
> To: William Mills <[email-masked]>; Nico Williams <[email-masked]>
> Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Tuesday, September 4, 2012 1:30 PM

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:43:02 -0500

> based on GSS naming extensions.

I should add that if it is absolutely essential that there be no risk
of an existing server SASL application not considering *both* IDs then
I think you *must* combine the two (unambiguously, parseably) into a
single authcid value.

> NO.  The OAuth mechanism CANNOT INTERPRET OR MODIFY OR PROVIDE an authz-id.

And I should clarify: the mechanism is only allowed to transport an
application-provided authz-id.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 20:43:30 +0000

>The question is: which ID is best to report as the authcid: the user,

Almost certainly the user. The OAuth mechanism should be evaluating the
suitability of the token, and part of that involves the policy decision
about who can wield tokens for some set of users, I would imagine.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 13:46:47 -0700 (PDT)

So it appears we have come around to the point where authz-id is useless in this context for what I need.  I should ignore it completely, and put the user field back into the SASL payload because we want that in plain text?

----- Original Message -----
> Sent: Tuesday, September 4, 2012 1:40 PM

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:47:25 -0500

> You're directly contradicting what others have said I think?

I'm not.

The authz-id, for the umpteenth time (subtext: I'm frustrated that you
do not appear to acknowledge this), is from a namespace, and of a
syntax that are specified by the application protocol.  And the
mechanism does not and CANNOT know what that protocol is.  Indeed, the
set of application protocols is *open*, so that even if the mechanism
could know what application is using it, it cannot know the
application protocol's authz-id namespace and syntax.  So there's
simply nothing that the mechanism can do with the authz-id other than
to transport it.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 20:47:24 +0000

>You're directly contradicting what others have said I think?

I don't believe I am, no. We've said over and over that the authz-id is
not a concept that you will see in GSS or in your mechanism itelf because
it's a SASL/application layer issue to pass it and process it. Your
mechanism knows nothing about it. You are conflating that authz-id with
the second ID in the OAuth token and they are not the same.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:50:46 -0500

> So it appears we have come around to the point where authz-id is useless in this context for what I need.  I should ignore it completely, and put the user field back into the SASL payload because w…

The user field would be in what would be the GSS payload.  It's fine
there.  But I thought that OAuth surely already had ways to indicate
both IDs anyways -- what am I missing?

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 20:54:32 +0000

On 9/4/12 4:46 PM, "William Mills" <[email-masked]> wrote:

>So it appears we have come around to the point where authz-id is useless
>in this context for what I need.  I should ignore it completely, and put
>the user field back into the SASL payload because we want that in plain
>text?

No, that is not IMHO what you want. You could break GSS support by
creating your own field to carry the authz-id in SASL, but you would still
be breaking the essential abstraction by trying to tie the authz-id to
something inside the OAuth token and you just shouldn't (possibly even
"can't") do that.

If you need to expose both OAuth identities to the application you can't
solve that by trying to make one of them the authz-id. You simply don't
control that field, the application protocol does.

In this particular case, I really don't think you have a problem. The
OAuth token is issued for some user identity. The fact that there may be a
delegate identity is useful to know in some contexts but I think for the
vast majority of cases, it's consumed by the OAuth mechanism, validated
against policy, and that's that. It's the user's identity that you surface.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 15:59:35 -0500

> mechanism, or at least translatable into it I suppose.

You can generally use any name type in the GSS_Import_name() call that
the mechanism supports.  HOWEVER, the name type reported by
GSS_Display_name() on an MN (specifically: the name returned by
GSS_Accept_sec_context() for the initator principal, or the names
returned by GSS_Inquire_context()) can and typically are
mechanism-specific.

The classic example of this is the Kerberos mechanism.  Since the
concept of "name type" is informative in the Kerberos protocol, and
since it's often lost, most (if not all) of the acceptor
implementations return GSS_KRB5_NT_PRINCIPAL_NAME as the name type of
MNs.

In the GSS naming extensions document (which is on the RFC-Editor
queue and practically done) we added a function for displaying a name
as a given generic name type if possible: GSS_Display_name_ext().
With this function you could ask the mechanism to display an MN as a
GSS_C_NT_USER_NAME, and it will fail if that makes no sense.  A
Kerberos mechanism implementation might simply do this only for a)
principals from the "default" realm (or the same realm as the acceptor
princ, perhaps), b) that have a single component in their name (a
Kerberos implementation on an OS that supports users from multiple
domains might only apply (b)).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 16:14:11 -0500

I should add that mechanisms with a single name-type can and should
use the generic name types in their GSS_Display_name()
implementations.

But even OAuth surely can handle more than one name type?  Sure, users
are users, but agents are not.  Of course, we could pretend that
agents are users, but we cannot impose a naming convention for agents
and say that they are usernames: generic GSS apps wouldn't know about
that convention.  True, generic GSS apps may not know about new name
types either (should we need one here), but then, generic GSS apps are
supposed to use the exported name token as the driver for
authorization (and now also the naming extensions, of course).

In practice pre-naming extensions GSS acceptor (server) apps come in
several flavors:

 - those that parse mech-specific name type (sigh)

 - those that use exported name tokens as a lookup key

 - those that effectively implement some extension by which to ask the
mechanism for "cooked" authz data (a "get an access token" or "get a
UID and a list of GIDs" function)

 - those that effectively implement some extension by which the
mechanism can implement an authorization function (a "userok"
function)

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 21:26:55 +0000

>use the generic name types in their GSS_Display_name()

I'll have to dig into my notes from this summer to ask anything more
specific, but I believe we ran into constraints that made it impractical
to define a new name-type and accomplish much with it using existing
target applications. But I could be confused about what the problem was. I
just know that at the moment I have not yet defined any SAML name-types.

>In practice pre-naming extensions GSS acceptor (server) apps come in

This is much of what's missing when one sets out to define a mechanism.

>mechanism can implement an authorization function (a "userok"

I think this is missing from the conversation because that function takes
the moral equivalent (perhaps the actual equivalent) of the authz-id from
SASL as input. So when William says "my mech needs that ID", I think this
is how it gets it. Not during processing of the mechanism exchange itself
but in an authorization hook.

But since that hook is nowhere in any specs, that's not clear to mech
authors.

And to elaborate on that, I think that if the mechanism implementer wanted
to impose a rule that the userok() code compared the proposed value to
something in the OAuth token, it could do so. But not as a matter of
mechanism specification, only implementation.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 16:37:04 -0500

> just know that at the moment I have not yet defined any SAML name-types.

Any GSS mechanism specification kinda needs to cover this :)

For SCRAM it was rather easy.

> This is much of what's missing when one sets out to define a mechanism.

Well, some of this is covered in RFC2743, but not all, and very dryly anyways...

> but in an authorization hook.

A userok function takes an authcid and authz-id and returns TRUE or
FALSE: TRUE if the authcid is allowed access to the given authz-id.
Except that typically a userok function only applies to one particular
authz-id namespace/syntax.

The traditional examples are krb5_kuserok() and gss_userok(), which
treat the authz-id as a Unix username.  An LDAP server would first
have to map the SASL authz-id onyo a Unix username if it wanted to use
such a userok() function.

> But since that hook is nowhere in any specs, that's not clear to mech

In practice authorization is a local problem, so a mechanism
specification can't really say much about it.  Of course, with SAML
and fine-grained authorization data delivered by mechanisms the
situation changes somewhat: we can now at least specify that
fine-grained authz data and we can cover enough use cases with it that
generic, portable mechanisms applications are now feasible.

> mechanism specification, only implementation.

Indeed!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 16:49:56 -0500

It's interesting how to a large extent these are generic matters, not
ones specific to GSS or SASL.  These problems and concepts show up in
pure TLS apps too.

You also get why we needed naming extensions...

BTW, I wish we'd added a function by which to list the generic name
types that an MN could be interpreted as...  I wish we'd covered the
issuer name issue in time as well.  HOWEVER, Sam and I have realized
that a lot of these "I wish we'd added this other naming extension"
cases can almost all be handled... via the name attributes concept
anyways.

For example, the NAME of the issuer of an MN could be obtained by
asking for the value of an attribute that is the issuer.  The raw
value(s) would be the exported name token form of the issuer NAME, and
the display_value(s) would be the display form!  And to get the issuer
of a given attribute value?  Just prefix that issuer attribute URI to
the attribute in question!  The concept of composable attribute names
is extremely powerful.  Let's call these prefixes "meta-attributes".

This is something I've been meaning to write an I-D about.  The first
set of meta-attributes I want to define:

 - issuer (this would correspond to 'realm' in the case of the
Kerberos mechanism)

 - trust transit path (here the set of values would form the path)
(remember, in GSS sets are order-preserving)

 - the transit policy checked flag

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 21:53:24 +0000

>Any GSS mechanism specification kinda needs to cover this :)

Cover it, yes, but not necessary define anything new, or am I wrong?

I peeked at some old emails, and I think the problem was that on the
client, with a GSS-only app, you import a name that's got to be
understandable to the user (the thing he types in) and that's by necessity
going to imported via a simple name-type. Turning that into a SAML
name-type has no value because it doesn't mean anything. It won't match
what the IdP actually issues as a SAML name, etc.

It also means nothing as a format for building ACLs because nobody's going
to build ACLs based on SAML names (if they even could, usually not). So
that left no use case for defining a name-type that would carry the
"native" SAML name. What is the use case that would require it?

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 17:12:24 -0500

> Cover it, yes, but not necessary define anything new, or am I wrong?

The minimum a GSS mech spec must do is:

 - specify what generic name types (if any) it supports
 - specify what mechanism-specific namet types (if any) it supports
 - the mech must support at least one name type
 - for an Internet standards-track mech it really should support at
least GSS_C_NT_HOSTBASED_SERVICE
 - specify how to map from generic name forms to mechanism-specific
name forms, including, too, how to "canonicalize" names (but see
below)

 - specify an exported name token format

Optional:

 - for naming extensions a mech spec should also specify how to map an
MN to a give name type.  And possibly (I want to add this) how to
determine what generic name types an MN can be displayed as.

 - specify how to compare names

> what the IdP actually issues as a SAML name, etc.

Right.  This mostly is about how we go from what the user typed in to
what the mechanism wants under the hood.

The authorization problem is less critical because as long as you
specify an exported name token format you can do *something*.

> "native" SAML name. What is the use case that would require it?

Well, the canonical method of authorization in RFC2743 is to call
GSS_Export_name() and then do octet string comparisons (length +
memcmp()) or lookups using the exported name tokens...

That's... kinda difficult to use effectively in practice because that
means that GSS dictates ACL form, and because name canonicalization is
a bit of a thing of the past in a world of fine-grained authorization
and of privacy protecting gateways.  And who wants the security
framework to dictate their ACLs?  Active Directory and NTFS use ACL
forms dictated by the OS, not by GSS, and that's just one example.
It's hard to imagine an RFC2743-pure world of applications.

[Sure, we could pretend that privacy-protected names are just
anonymous names, but we still need to use the fine-grained authz data
delivered by the mechanism.  But this only covers some use cases and
requires naming extensions anyways.  Another thing we could do is to
encode all the fine-grained authz data into the display name form, but
that's no good from a usability perspective.  And we can't encode
fine-grained authz data in exported name tokens because that would
break any RFC2743-pure apps that exist (some do).  The only real
choice we have is to use naming extensions.]

I think we now want to say that sorry, some mechanisms don't support
"canonical names", and/or don't support a canonicalization service
(specifically: GSS_Canonicalize_name()), and/or don't support
GSS_Export_name().  Such mechanisms are only really usable in
conjunction with GSS naming extensions, therefore they must support
those.

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 15:26:56 -0700 (PDT)

No you're confused.  I don't care at all about the actual authz-id.  Forget that part.  Help me solve the problem of having a plain text copy of the user identity for the resource being accessed available to the mechanism.

----- Original Message -----
> Sent: Tuesday, September 4, 2012 1:54 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 22:32:00 +0000

On 9/4/12 6:26 PM, "William Mills" <[email-masked]> wrote:

>No you're confused.  I don't care at all about the actual authz-id.
>Forget that part.

Ok.

>Help me solve the problem of having a plain text copy of the user
>identity for the resource being accessed available to the mechanism.

Who is supplying that identity? Where does it come from and for what will
it be used?

It isn't what Ryan was asking for. Not based on what he posted anyway. So
I haven't seen any explanation of it that I understand.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 22:34:14 +0000

>and of privacy protecting gateways.

Right.

>  And who wants the security

Ok, so...

>choice we have is to use naming extensions.]

Agree, so...

>conjunction with GSS naming extensions, therefore they must support

And that's where I'm at. So thus far, I haven't bothered to include a MN
for SAML in my draft. I feel like it's only valuable if I can understand
how it will get used. But it wouldn't be rocket science, it's just some
canonical XML.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 15:40:23 -0700 (PDT)

The client will provide that identity, which in IMAP for example will be the username fore the mailbox being accessed.  

----- Original Message -----
> Sent: Tuesday, September 4, 2012 3:32 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 22:46:23 +0000

On 9/4/12 6:40 PM, "William Mills" <[email-masked]> wrote:

>The client will provide that identity, which in IMAP for example will be
>the username fore the mailbox being accessed.

That doesn't answer the rest of my question. So that's where it comes
from, fine. I think that's the SASL authz-id, which is not what you want
to hear. But leave that aside; at the point that client enters that, what
is that you're trying to do with it and on which end(s)?

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 4 Sep 2012 22:34:14 +0000

Right.

Ok, so...

Agree, so...

-- Scott

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Sep 2012 15:53:11 -0700

> the username fore the mailbox being accessed. 

In IMAP, the username for the mailbox being accessed is exactly the SASL
authz-id, which you're not allowed to touch as part of a SASL mechanism.
It's up to the IMAP server, outside of SASL, to decide whether a given
authenticated identity is permitted to assert that authz-id.

I suspect that one of the things that's making this complex is that SASL
is designed to be purely an authentication protocol.  It conveys
authentication information (plus a client-provided authz-id that it only
passes through but doesn't validate), and leaves all authorization to the
application.  OAuth, on the other hand, *isn't* purely an authentication
framework; it also has an authorization component.

You're going to have some real difficulty trying to wedge the
authorization bit into SASL, since SASL by design tries to stay completely
out of the authorization business.

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 16:14:46 -0700 (PDT)

OK, so authz-id is in fact the piece of data I need but the mechanism can't use it?  

Say I've got a bad guy hitting my server and in authz-id he sends [email-masked], but the credential he sends is for [email-masked].  Does the SASL mechanism succeed and then the application has to compare the two values?

----- Original Message -----
> From: Russ Allbery <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Tuesday, September 4, 2012 3:53 PM
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Sep 2012 16:17:27 -0700

> Say I've got a bad guy hitting my server and in authz-id he sends
> [email-masked], but the credential he sends is for [email-masked]. 
> Does the SASL mechanism succeed and then the application has to compare
> the two values?

Correct.  He has successfully authenticated as [email-masked], at which
point SASL's role in the protocol is complete.  SASL communicates both
that identity and the requested authz-id to the application and exits the
picture.  The decision beyond that point is an authorization decision,
which SASL leaves to the application.

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 18:20:42 -0500

> OK, so authz-id is in fact the piece of data I need but the mechanism can't use it?

Yes and yes.

> Say I've got a bad guy hitting my server and in authz-id he sends [email-masked], but the credential he sends is for [email-masked].  Does the SASL mechanism succeed and then the application has to…

The application performs an authorization check, yes.  Who knows,
maybe good and evil go together and evil has access to good's mailbox
intentionally.

The key is that the mechanism transports the authz-id *with* integrity
protection.  (Confidentiality protection might be nice, but GS2
doesn't provide that, sorry.)  Then the application decides if the
authcid gets access to the requested authz-id.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 00:11:24 +0000

On 9/4/12 7:20 PM, "Nico Williams" <[email-masked]> wrote:
>protection.

I believe that's only in the case where channel binding is possible.
Otherwise, it's left to TLS to protect it all and you punt.

I note that since the vastly more common OAuth case will be bearer tokens
and no CB.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 00:13:42 +0000

>Does the SASL mechanism succeed and then the application has to compare

If you read some of the other messages in the thread that I forked off,
you'll see the userok function notion mentioned. There are some APIs that
hook into a mechanism and pass in a proposed userid (in your example,
good@) and then the implementation can say "I'm going to validate the
claimed ID against my OAuth token's contents" if you want it to.

That's all fine, it's just not something on the wire in the mechanism or
mandated.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 17:14:33 -0700 (PDT)

OK, so based on this is this:

    Some OAuth schemes can carry both a user identity and a "proxy" identity,
    for example an OAuth 1.0a <xref target="RFC5849"/>mechanism where the 

    consumer key (oauth_consumer_key) identifies the entityusing the token 

    and the token itself identifies the user.  If both identitiesare needed 

    by an application the developer will need to provide a way to communicate 

    that from the SASL mechanism back to the application.
safe to say?

Thanks,

-bill

----- Original Message -----
> Sent: Tuesday, September 4, 2012 4:17 PM

---

From: Luke Howard <[email-masked]>
Date: Wed, 5 Sep 2012 10:17:42 +1000

> Otherwise, it's left to TLS to protect it all and you punt.

Well, GS1 (RFC 2222) integrity protected it with GSS_Wrap(). But that's a historical footnote now.

-- Luke

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 00:21:24 +0000

>    that from the SASL mechanism back to the application.

It depends what level of interop you're looking for, I guess. Nico was
trying to say that if you wanted to nail that down, you could do that by
specifying an encoding of the two in the single value communicated back.

Nobody's saying that's wrong, only that conflating it with some kind of
verification of the authz-id is wrong.

You could do this by specifying a GSS name-type specific to this mechanism
that encoded the two bits of data in some way. What I can't really say is
how that impacts SASL apps in particular, but others should be able to
address that question.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 17:26:19 -0700 (PDT)

> specifying an encoding of the two in the single value communicated back.

Yeah, that's probably the way it works.  But now that I think I've grokked this
I was gonna leave it up to the mech developer and application to decide.  Just
noting that it might need to be communicated.  I can get more specific but I can
see custom implementations doing something different.

-bill

----- Original Message -----
> To: William Mills <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Tuesday, September 4, 2012 5:21 PM
>>     Some OAuth schemes can carry both a user identity and a 
> "proxy"
>> identity,

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 00:29:53 +0000

>see custom implementations doing something different.

The problem, I think, is that you generally want the app layer independent
of the mechanism implementation, so getting them to behave in custom ways
isn't really the goal. Obviously if you just package it up for one
mechanism to run inside a custom app, it doesn't matter.

My opinion, as I have said, is that in practice the delegation would be
evaluated with the mechanism and not exposed, or that it would be done via
hooks that call into the mechanism explicitly with the authz-id and then
it gets to do its own custom eval of both the identities in the token.
Either way, I don't think both need to be exposed to the application to do
useful things with them.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 4 Sep 2012 17:34:32 -0700 (PDT)

Yeah, but in cases where you're interested in what 3rd party is using delegated credentials you want that in the app data for logging stuff.  It probably does want to get communicated back.

----- Original Message -----
> Sent: Tuesday, September 4, 2012 5:29 PM

---

From: Luke Howard <[email-masked]>
Date: Wed, 5 Sep 2012 10:34:54 +1000

> see custom implementations doing something different.

You probably want to say that the SASL authentication identity corresponds to the OAuth user identity.

Optionally you might define a well known GSS naming attribute (URN) that conveys the OAuth proxy identity. Nico or Sam Hartman could give you some guidance on this.

-- Luke

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 00:47:22 +0000

On 9/4/12 8:34 PM, "William Mills" <[email-masked]> wrote:

>Yeah, but in cases where you're interested in what 3rd party is using
>delegated credentials you want that in the app data for logging stuff.

Possibly, yes, or it could be logged by the mechanism.

>It probably does want to get communicated back.

In SASL terms, I don't know that you'd have much option but to carry it in
a combined value. In GSS, you definitely can just expose it as a name
attribute and/or you can carry it in a custom mechanism name-type.

- Scott

---

From: Luke Howard <[email-masked]>
Date: Wed, 5 Sep 2012 10:55:38 +1000

> attribute and/or you can carry it in a custom mechanism name-type.

I suspect carrying it in a combined value is going to cause problems with mechanism-agnostic applications that assume, in the absence of an explicit authorisation identity, the authentication identity can be interpreted similarly. If that makes any sense...

-- Luke

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 01:01:04 +0000

On 9/4/12 8:55 PM, "Luke Howard" <[email-masked]> wrote:

>I suspect carrying it in a combined value is going to cause problems with
>mechanism-agnostic applications that assume, in the absence of an
>explicit authorisation identity, the authentication identity can be
>interpreted similarly. If that makes any sense...

Yes, that was really what I expected somebody would say. ;-)

But I don't know if SASL APIs in general would get you access to the GSS
name underneath to be able to extract the data in other ways. That's
clearly better.

In fact, I'll just say that I don't think OAuth has only those two pieces
of information in play, any more than SAML would. A SAML assertion has
lots of information the app might want, even aside from extensible user
attributes, which I know that OAuth will also have to support. So at some
point, I think you have to accept that if all you have is "userid", that's
just for compatibility/normalization and that newer apps with real needs
are going to have to go after the GSS attributes.

You can handle the particular case of the client ID in OAuth alone, but
that's just going to solve a small part of the general problem.

-- Scott

---

From: Russ Allbery <[email-masked]>
Date: Tue, 04 Sep 2012 18:02:33 -0700

"Cantor, Scott" <[email-masked]> writes:

> In fact, I'll just say that I don't think OAuth has only those two
> pieces of information in play, any more than SAML would. A SAML
> assertion has lots of information the app might want, even aside from
> extensible user attributes, which I know that OAuth will also have to
> support. So at some point, I think you have to accept that if all you
> have is "userid", that's just for compatibility/normalization and that
> newer apps with real needs are going to have to go after the GSS
> attributes.

Yes, this sounds right to me too.

---

From: Luke Howard <[email-masked]>
Date: Wed, 5 Sep 2012 11:07:14 +1000

Cyrus does. You could do something similar with SSPI.

Sent from my iPhone

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 21:10:50 -0500

> Cyrus does. You could do something similar with SSPI.

What Luke said.

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Sep 2012 23:20:11 -0500

> Otherwise, it's left to TLS to protect it all and you punt.

Indeed.  GS2 kinda sorta (no, really) presumes CB...

> I note that since the vastly more common OAuth case will be bearer tokens

I'll pretend that that isn't so and then we can pretend that bearer
mechanisms (or any half round trip mechanisms; a 1 round trip bearer
token mech could handle CB) handle CB :)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 05 Sep 2012 08:48:46 +0200

> about who can wield tokens for some set of users, I would imagine.

I agree.  SASL only has the concept of clients and servers -- it doesn't
have a concept of agents.  So from the SASL point of view, I believe the
agent could be seen as acting as a proxy for the user, so the identity
to report should be the user's.

/Simon

---

From: William Mills <[email-masked]>
Date: Wed, 5 Sep 2012 07:33:28 -0700 (PDT)

OK, so it sounds like the proposed text is OK?

>To: "Cantor, Scott" <[email-masked]> 
>Cc: Nico Williams <[email-masked]>; William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 4, 2012 11:48 PM

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Sep 2012 11:01:37 -0500

> to report should be the user's.

Agreed.  My suggestion of using a composite of the two IDs was only in case
that William felt quite certain that apps must take both into account, so
much so that existing apps must fail when used with this mechanism.  But i
don't think that's really the case.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 5 Sep 2012 16:04:37 +0000

>OK, so it sounds like the proposed text is OK?

What I recall looked ok. You could spin a new draft or just drop a pointer
to where you ended up. You may want to drop in a reference to the name
attributes RFC and just note the possibility of exposing additional OAuth
data through that mechanism.

-- Scott

---

From: William Mills <[email-masked]>
Date: Wed, 12 Sep 2012 23:46:48 -0700 (PDT)

Submitted -07 http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-07.txt

http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/

-bill

>Cc: Nico Williams <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, September 5, 2012 9:04 AM