Re: Heirarchical error codes

[Rob Earhart <rob@xxxxxxxxxxxxxx>]

On Fri, 19 Mar 1999, Doug Royer wrote:
> Untagged can get messy if we allow capability in multiple states as
> shown in the straw-man draft (and I hope we keep that).  I am hopping
> that you can only see the authentication mechanisms in the connected
> state.  And the rest of the capabilities after authentication.
>
> For example, now that I know who you (authenticated entity) are, you
> also have the capability to use x, y, and z. I could also see a CS
> implementation sending different results to an authenticated CUA
> depending if they were inside or outside of a firewall.

  Sure; I think that's reasonable.  What you'd want to do is send another
CAPABILITY message after authentication.  There's some precedent for this,
too -- if TLS is negotiated, the list of available SASL mechanisms may
change (plaintext login is permissible in IETF protocols, as long as it
only occurs over an encrypted channel).

> So the client would need to know how to authenticate initially, then
> could query the CS after authentication for more capabilities.

  I think it'd be better to have both sides send new capabilities lists as
the set of capabilities they offer change; there's no way that one side
can know when to ask.  (This does propose a problem if one side removes
something from its list of capabilities, though; what if a command in
flight makes use of the removed capability?  Maybe new capability messages
should simply augment older ones, providing no way to remove previously
declared capabilities...)

  Note, also, that just because a capability is offered doesn't mean that
it won't be rejected if used; it just means that using it isn't a
protocol-level syntax error.  A client can always get a "You're not
allowed to do that" message.

> Supporting a capability is one issue, how do we handle MUST for
> an implementation? What if for security reasons a particular 
> CS implementation requires that TLS MUST be used. How do we
> say that? Do we care?

  Such implementations should probably just not offer any SASL mechanisms
until TLS is negotiated, effectively preventing any transition to an
authenticated state until TLS is negotiated.

  )Rob