Subject: [BXXPwg] User Specific profile advertisement?

From: "Bob Wyman" <[email-masked]>
Date: Tue, 2 Jan 2001 13:25:50 -0800

I would like to be able to advertise different lists of available profiles
based on the identity of the users who connect to my server. How do I do
this?

In BXXP, the greeting element allows each peer to advertise the profiles it
supports by sending a greeting message. Thus, a peer can advertise supported
profiles either on initial connection or when the greeting is sent after
transport security is negotiated. This means that one set of profiles might
be advertised to peers that connect with no transport security while a
second, identical or different, set of profiles can be advertised once
transport security has been negotiated. This is goodness. For some obscure
reason, I may only want to send my profile advertisements over secure lines
or only to those who have established their ability to use some particular
kind of transport security.

It would also be desirable to allow the advertising of profiles to be
dependent on authentication. However, the User Authentication negotiation,
unlike that for Transport Security, does not appear to provide for a new
greeting message once complete. This is unfortunate since there are a number
of situations in which I would only want profiles to be advertised to
specific individuals or members of groups. Am I misreading the spec (I'm new
to BXXP.)? Or, is there a mechanism available to allow user specific profile
advertisement? If not, should one be added? (i.e. perhaps require or permit
a new greeting message after User Authentication?)

        bob wyman

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Marshall T. Rose" <[email-masked]>
Date: Tue, 2 Jan 2001 13:56:11 -0800

> based on the identity of the users who connect to my server. How do I do

hi. the short answer is that you can do this, but it isn't easy.

you already stated the sub-optimal solution: if you use a transport security
profile to authenticate then when the underlying transport security
negotiation completes, all cached information is discarded and a new
greeting is generated. you could make this greeting authenticator-specific
if you wanted.

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
think that 6 months from now, a given server might be offering APEX edge
service on one port, the APEX relay service on another, the syslog service
on a third, etc. in each case, the initiating peer uses SRV records to
figure out the port to connect to.

from a philosophical perspective, services decide which users get to do
what; it's easy to see a useful system based on "i want to do this specific
class of transactions, and i authenticate as mrose"; it's a lort hard to
imagine a useful system based on "i authenticate as mrose, so what classes
of transactions am i allowed"?

/mtr

---

From: "Bob Wyman" <[email-masked]>
Date: 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
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.

> 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

---

From: "Marshall T. Rose" <[email-masked]>
Date: 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" <[email-masked]>
To: "Marshall T. Rose" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, January 02, 2001 15:03
Subject: Re: [BXXPwg] User Specific profile advertisement?