[BXXPwg] User Specific profile advertisement?

Marshall T. Rose mrose+mtr.netnews@dbc.mtview.ca.us
Tue, 2 Jan 2001 15:22:58 -0800


well, there's nothing that stops you from making problems as hard (or easy)
as you want. but this all sounds like the hard way: the wrong thing is being
optimized for.

you can certainly have a server advertise lots of profiles in a greeting,
and then, after authentication, decide whether it will allow a given profile
to be started or not. or maybe you can start it, but the authorization
policy allows only a subset of the operations, etc., etc.

/mtr

----- Original Message -----
From: "Bob Wyman" <bobwyman@earthlink.net>
To: "Marshall T. Rose" <mrose+mtr.netnews@dbc.mtview.ca.us>;
<bxxpwg@lists.invisibleworlds.com>
Sent: Tuesday, January 02, 2001 15:03
Subject: Re: [BXXPwg] User Specific profile advertisement?


> 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
> server.
>
> 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
> do
> > the selection for you. for example, i don't think that it's unreasonable
> to
>
> 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
>
>
>