[BEEPwg] Clarification on RFC 3080, 4.1.3

RL 'Bob' Morgan rlmorgan@washington.edu
Fri, 18 Oct 2002 13:58:32 -0700 (PDT)


On 16 Oct 2002, Jered Floyd wrote:

> At the end of section 4.1.3 of RFC 3080 (bottom of page 43), SASL's
> EXTERNAL mechanism is described.  It ends with:
>
>    if present, the authentication identity must be consistent with the
>    credentials provided by the external authentication service (if the
>    authentication identity is empty, then an authorization identity is
>    automatically derived from the credentials provided by the external
>    authentication service).
>
> In the parenthetical comment, is the word "authorization" meant to
> be "authentication"?  I believe this sentence is trying to state that
> if an authentication identity is provided via SASL EXTERNAL, it must
> match the external authentication identity, however if it is not
> present the authentication identity is taken from the external
> credentials.

Actually, I believe the paragraph in RFC 3080 should be written as:

   o  if present, the authorization identity must be consistent with
      the credentials provided by the external authentication service
      (if the authorization identity is empty, then an authorization
      identity is automatically derived from the credentials provided by
      the external authentication service).

(Sorry if I messed this up when I supplied that text, Marshall.)

RFC 2222 specifies that a SASL profile of a security mechanism should
provide the ability for the client to assert an "authorization identity",
which tells the server what identity the client would like to have used
for authorization purposes, regardless of any identity provided or implied
by the authentication mechanism.  Of course, the server should have policy
about which authenticated entities can assume which authorization
identities.  This SASL feature is best understood as supporting proxy or
3-tier authentication, where an intermediate service authenticates to a
backend service as itself, but says "please treat these requests as coming
from user <foo>".  But it can be used in other ways too.  So the above
paragraph is explaining what to do with the authorization identity, if
supplied, and what to do if not.

See section 3 of RFC 2829 for some general discussion of this.  There has
also been lots of discussion of the subtleties of authorization ids on the
ietf-sasl@imc.org list.  We're hoping that the revision to RFC 2222
(currently draft-myers-saslrev-02.txt) will clear up some common
questions about this.

 - RL "Bob"