Subject: Re: Heirarchical error codes

From: Doug Royer <[email-masked]>
Date: Fri, 19 Mar 1999 15:32:55 -0800 (PST)

> Date: Fri, 19 Mar 1999 10:46:39 -0500 (EST)
> From: Rob Earhart <[email-masked]>
> 
> > Are you thinking of some sort of CAPABILITY list that the client sends the
> > server, and a similar set of capabilities that the server returns based on
> > what it received from the client??
> 
>   Almost; I'd rather see both simply send capability lists when the
> connection is initialized.  For instance, at session startup, one might
> see
> 
>   C: * CAPABILITY CAP XMLCAL
>   S: * CAPABILITY CAP SASL ("KERBEROS_V4" "GSSAPI" "DIGEST-MD5") TLS
> 
> (using * instead of a normal tag because these aren't commands; they're
> information which doesn't require a reply.) 

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.

So the client would need to know how to authenticate initially, then
could query the CS after authentication for more capabilities.
Requireing a tagged capability command?

>   The server probably shouldn't restrict its list based on what it gets
> from the client; it's useful to see everything the server's capable of.
> After this exchange, both sides know what the other's capable of dealing
> with, and can restrict what they speak to the subset of the capabilities
> they know about for which the other side has announced support.

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?

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Rob Earhart <[email-masked]>
Date: Fri, 19 Mar 1999 21:44:03 -0500 (EST)

> 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).

> 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.

> CS implementation requires that TLS MUST be used. How do we

  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