Subject: [BEEPwg] Clarification on RFC 3080, 4.1.3

From: Jered Floyd <[email-masked]>
Date: 16 Oct 2002 18:06:54 -0400

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.

--Jered

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 18 Oct 2002 13:58:32 -0700 (PDT)

> present the authentication identity is taken from the external

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
[email-masked] 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"