[BXXPwg] User Specific profile advertisement?

Bob Wyman Bob Wyman" <bobwyman@earthlink.net
Tue, 2 Jan 2001 15:03:18 -0800

Marshall T. Rose wrote:
> hard to imagine a useful system based on
> "i authenticate as mrose, so what classes
> of transactions am i allowed"?
Imagine: A site uses a single BEEP port to offer a variety of services to a
variety of customers who are provided with varying degrees of service. Of
the 10 services available, "basic" customers are allowed to use services 1-5
while "premium" customers are allowed to use services 1-10. All 10 services
are known to a client applications that enables or disables various user
interface elements based on which profiles are available on the currently
active connection. A stock market site might, for instance, allow Edgar
searching for free, yet require a valid UserID in order to access "portfolio
management." The client application might be something like Groove, thus
providing a basic framework within which many "tools" can be run. The result
is that there might be dozens or even hundreds of profiles that could be
supported by any particular client configuration. Thus, it would be ugly to
have to query for each possible profile every time the client connects to a

In a slightly different scenario, there might be "stealth" services
available (such as use of proto-type systems or proprietary applications),
access to which would be reserved to specific users and whose availability
the site did not want to publish. (Note: In some contexts, simply publishing
the name of a service can give away critical information. Even publishing a
service with an obscure name might cause people to seek additional
information - via probes or off-line means. Thus, some profiles should not
be advertised either by greeting messages or DNS entries.) Admittedly, one
can say that the stealth service, even if not advertised in the greeting
message, could still be requested by the client, however, given a
sufficiently paranoid site, folk may wish to ensure that clients for
"stealth" services never risk asking for the service from a server that does
not provide it. Rejected profile requests might be logged and thus be open
to inspection. (i.e. Hacker says: "The log says that someone from 'Bank of
FooBar' asked for access to the 'BigBucks' service. Let's see if we can find
it on one of their servers...)

> you already stated the sub-optimal solution:
Let me clarify: You appear to be suggesting that I can do Authentication
specific greeting messages by doing Authentication first and then doing
Transport Security negotiation second. The greeting message emitted after
the Transport Security negotiation could then be dependent on the earlier
authentication? I had been assuming that Authentication had to happen after
Transport Security negotiation since such negotiation causes all cached
information to be discarded. Is Authentication information NOT discarded as
a result of Transport Security negotiation? If this "pattern" works, then
should one suggest that as a "best practice" peers should always do
Authentication first and transport security second in order to enable
Authentication specific greetings messages?
Even if this works, there is still the problem of how to do this Transport
Security negotiation is not necessary. I suppose one could define a way to
negotiate for "no-transport security" in order to trigger the greeting
message, however, that strikes me as very ugly. It would seem to be easier
to simply allow a greeting message to appear after Authentication.

> an alternative approach is to offer BEEP on multiple TCP ports, and have
> different profiles available on each port. you could then use the DNS to
> the selection for you. for example, i don't think that it's unreasonable

If DNS satisfied all profile advertisement requirements then it wouldn't be
sensible to do profile advertisement in BEEP... In some cases, as described
above, one does not want to publish the availability of services except to a
very strictly controlled community. In other cases, for instance my personal
machine connecting through an ISP who does not let me diddle with DNS
settings, I may not be able to make appropriate modifications to the DNS
entries. Even in a corporate environment, it can sometimes be hard to get
the local MIS folk to make DNS changes when desired.

I really like that BEEP can provide a single access port that I can use to
advertise and support a wide range of services much in the same way I can
use a single web server to provide access to a variety of services. I do, of
course, see the value of being able to use a mechanism to direct or redirect
users to different ports based on the service they require. That, however,
should be the subject of a later discussion...

        bob wyman