Re: coments on draft-ietf-sacred-protocol-bss-00

I agree with Bob on the use of authorization identities. I can also
see other usages for these, e.g. a common set of role-based
credentials which may be accessed when authenticating as belonging to
a certain set of users.

Regarding error codes, I really don't want to continue that thread,
but I can't help noting that the current protocol I-D defines new BEEP
error codes to cater for SACRED specific errors.

-- Magnus

On Thu, 13 Dec 2001, RL 'Bob' Morgan wrote:

>
>
> > Explain to me why I need separate authentication and authorization
> > (sasl) identities for sacred?
> >
> > If its not needed for sacred, IMHO, it shouldn't be in.
>
> Typical scenarios for other protocols that use authorization ID are
> administrator access and proxy/middle-tier access.  I can imagine a setup
> where it's useful for a sysadmin to have the ability to do upload/download
> operations "as the user" as part of problem determination.  I can also
> imagine setups using proxy frontends to deal with different authentication
> capabilities in clients.  Just because some folks wouldn't use them
> doesn't mean these scenarios should be forbidden.
>
> RFC 2222 says that a protocol defining its use of SASL has to provide:
>
>    5. A specification of how the authorization identity passed from the
>       client to the server is to be interpreted.
>
> So I think the point is to permit implementations to do useful things with
> this without making it a burden for those that don't want to use it.
> Here's language that I think does that, replacing current language in 2.2
> of draft-ietf-sacred-protocol-bss-00.txt:
>
>   Implementations MAY support the use of the SASL authorization identity
>   field.  If present, the field is interpreted in an
>   implementation-specific manner to select a particular account, subject
>   to authorization controls applied by the server.  An unrecognized or
>   inappropriate authorization identity MUST cause the server to respond
>   with a 537 error code.
>
> I will also point out that handling this as an error is an example of the
> additional things that have to be reinvented at the application level if
> the unwise course of defining SASL in this protocol is pursued.  Using
> BEEP gives you language about handling authorization ID and error codes
> for free.
>
>  - RL "Bob"
>
>
>

-- Magnus
Magnus Nystrom
RSA Security