beepcore-java-users

[Beepcore-java-users] Requireing a profile

[Kevin K. <kk...@my...>]

In the SASL profile (or possibly a TLS) what is the mechanism used to
send out "530" errors if the server wants to require authentication. 

For example, when a server starts up, it registers both, SASL/ANONYMOUS
and ECHO... the desired result being that until the SASL/ANONYMOUS has
set credentials in the Session, all other startChannel messages (in this
case ECHO) will return with a <error code='530'> . 

If this is not done yet, where might it fit best?  A function of Session
for the error sending?  Possibly ProfileRegistry for initial setup or
TCPSessionCreator to setup the required auth?

thoughts? 

--Kevin Kress 

Re: [Beepcore-java-users] Requireing a profile

[William J. M. <wm...@ol...>]

I think this is a case where the profiles need to do the right thing, rather than
the core functionality.  I may be wrong.  

SASL sets a state in the session, but to some extent it is the profiles which
must honor this.  Tuning profiles which casue a new greeting to be exchanged
give the opportunity to register new profiles, and advertise them at that time,
which would do what you want, but SASL/ANONYMOUS does not cause a tuning reset 
in this way (as far as I know).

So for the ECHO example, you'd need a custom version that checks authentication 
in it's start message handler.

Someone please correct me if I am mistaken.

-bill

On Sun, Aug 04, 2002 at 05:20:46PM -0700, Kevin Kress wrote:
> In the SASL profile (or possibly a TLS) what is the mechanism used to
> send out "530" errors if the server wants to require authentication. 
> 
> For example, when a server starts up, it registers both, SASL/ANONYMOUS
> and ECHO... the desired result being that until the SASL/ANONYMOUS has
> set credentials in the Session, all other startChannel messages (in this
> case ECHO) will return with a <error code='530'> . 
> 
> If this is not done yet, where might it fit best?  A function of Session
> for the error sending?  Possibly ProfileRegistry for initial setup or
> TCPSessionCreator to setup the required auth?
> 
> thoughts? 
> 
> --Kevin Kress 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Beepcore-java-users mailing list
> Bee...@li...
> https://lists.sourceforge.net/lists/listinfo/beepcore-java-users

Re: [Beepcore-java-users] Requireing a profile

[Kevin K. <kk...@my...>]

This seems like a bit overkill to me.  If you think about tuing profiles
as a layer below the application profiles then a profile should have no
knowledge of the tuing profile that is operating under it.

Shouldn't it be the responsibilty of the core API to establish a chain
of dependancies that can be setup when the server session listener (in
this can TCPSessionCreator) is created?

If a simple dependancy scheme is implemented that would mean that all
supported profiles could be advertised upon the first greeting and
return error codes when start requests are attempted without proper
authentication or security in place.


For example:

3 profiles exist in parallel, Echo, TLS and SASL/OTP

Echo profile requires that SASL/OTP be in place.

SASL/OTP requires TLS

in this case you would need custom protocols for each profile to
properly handle this situation. =20

thoughts?

--Kevin Kress

On Sun, 2002-08-04 at 19:44, William J. Mills wrote:
> I think this is a case where the profiles need to do the right thing, rat=
her than
> the core functionality.  I may be wrong. =20
>=20
> SASL sets a state in the session, but to some extent it is the profiles w=
hich
> must honor this.  Tuning profiles which casue a new greeting to be exchan=
ged
> give the opportunity to register new profiles, and advertise them at that=
 time,
> which would do what you want, but SASL/ANONYMOUS does not cause a tuning =
reset=20
> in this way (as far as I know).
>=20
> So for the ECHO example, you'd need a custom version that checks authenti=
cation=20
> in it's start message handler.
>=20
> Someone please correct me if I am mistaken.
>=20
> -bill
>=20
> On Sun, Aug 04, 2002 at 05:20:46PM -0700, Kevin Kress wrote:
> > In the SASL profile (or possibly a TLS) what is the mechanism used to
> > send out "530" errors if the server wants to require authentication.=20
> >=20
> > For example, when a server starts up, it registers both, SASL/ANONYMOUS
> > and ECHO... the desired result being that until the SASL/ANONYMOUS has
> > set credentials in the Session, all other startChannel messages (in thi=
s
> > case ECHO) will return with a <error code=3D'530'> .=20
> >=20
> > If this is not done yet, where might it fit best?  A function of Sessio=
n
> > for the error sending?  Possibly ProfileRegistry for initial setup or
> > TCPSessionCreator to setup the required auth?
> >=20
> > thoughts?=20
> >=20
> > --Kevin Kress=20
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Beepcore-java-users mailing list
> > Bee...@li...
> > https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
>=20
--=20
Kevin Kress
kk...@my...

GnuPG Key ID: 92949032
Fingerprint : B7F9 2B08 6FC8 35CA 5B64  BD34 6A8B 325C 9294 9032

See Keyserver: http://www.keyserver.net/en/findkey.html
(search for "Kevin Kress" or "0x92949032")

Get GnuPG or PGP at http://www.pgpi.org

Re: [Beepcore-java-users] Requireing a profile

[William J. M. <wm...@ol...>]

Well, one of the major issues here is that once you start saying profile-X 
depends on SASL which shade of SASL?  All of them?  The "simple dependency
scheme" does not really end up simple I think.  

Also consider that you may not want to advertise all profiles before authentication
or encryption has been completed.

A note on tuning profiles, SASL is a tuning profile that affects the session
state, but does not issue a tuning reset.

The design decision we made was to leave this kind of thing out, because it can
be implemented in the profiles, there did not appear to be a general solution,
and perhaps the greatest consideration was that it adds a lot of complexity to the
wrapper.

Not to say that another wrapper could not be implemented with this kind of thing
added.  That's one of the reasons that we broke the code up the way we did.  Core
and utilities are separate.  The transport stuff can be utilized easily by another 
wrapper.

For the 3 profiles you talk about, only advertise TLS initially, after the tuning 
reset, advertise SASL and ECHO.  The only profile that need be custom is ECHO.
ECHO is not the greatest example here, but it will serve fine as a straw man.

-bill

On Mon, Aug 05, 2002 at 09:05:34PM -0700, Kevin Kress wrote:
> This seems like a bit overkill to me.  If you think about tuing profiles
> as a layer below the application profiles then a profile should have no
> knowledge of the tuing profile that is operating under it.
> 
> Shouldn't it be the responsibilty of the core API to establish a chain
> of dependancies that can be setup when the server session listener (in
> this can TCPSessionCreator) is created?
> 
> If a simple dependancy scheme is implemented that would mean that all
> supported profiles could be advertised upon the first greeting and
> return error codes when start requests are attempted without proper
> authentication or security in place.
> 
> 
> For example:
> 
> 3 profiles exist in parallel, Echo, TLS and SASL/OTP
> 
> Echo profile requires that SASL/OTP be in place.
> 
> SASL/OTP requires TLS
> 
> in this case you would need custom protocols for each profile to
> properly handle this situation.  
> 
> thoughts?
> 
> --Kevin Kress
> 
> On Sun, 2002-08-04 at 19:44, William J. Mills wrote:
> > I think this is a case where the profiles need to do the right thing, rather than
> > the core functionality.  I may be wrong.  
> > 
> > SASL sets a state in the session, but to some extent it is the profiles which
> > must honor this.  Tuning profiles which casue a new greeting to be exchanged
> > give the opportunity to register new profiles, and advertise them at that time,
> > which would do what you want, but SASL/ANONYMOUS does not cause a tuning reset 
> > in this way (as far as I know).
> > 
> > So for the ECHO example, you'd need a custom version that checks authentication 
> > in it's start message handler.
> > 
> > Someone please correct me if I am mistaken.
> > 
> > -bill
> > 
> > On Sun, Aug 04, 2002 at 05:20:46PM -0700, Kevin Kress wrote:
> > > In the SASL profile (or possibly a TLS) what is the mechanism used to
> > > send out "530" errors if the server wants to require authentication. 
> > > 
> > > For example, when a server starts up, it registers both, SASL/ANONYMOUS
> > > and ECHO... the desired result being that until the SASL/ANONYMOUS has
> > > set credentials in the Session, all other startChannel messages (in this
> > > case ECHO) will return with a <error code='530'> . 
> > > 
> > > If this is not done yet, where might it fit best?  A function of Session
> > > for the error sending?  Possibly ProfileRegistry for initial setup or
> > > TCPSessionCreator to setup the required auth?
> > > 
> > > thoughts? 
> > > 
> > > --Kevin Kress 
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Beepcore-java-users mailing list
> > > Bee...@li...
> > > https://lists.sourceforge.net/lists/listinfo/beepcore-java-users
> > 
> -- 
> Kevin Kress
> kk...@my...
> 
> GnuPG Key ID: 92949032
> Fingerprint : B7F9 2B08 6FC8 35CA 5B64  BD34 6A8B 325C 9294 9032
> 
> See Keyserver: http://www.keyserver.net/en/findkey.html
> (search for "Kevin Kress" or "0x92949032")
> 
> Get GnuPG or PGP at http://www.pgpi.org

Re: [Beepcore-java-users] Requireing a profile

[Marshall R. <mr...@db...>]

> A note on tuning profiles, SASL is a tuning profile that affects the
session
> state, but does not issue a tuning reset.

actually, this is not true. if a security layer is negotiated as a part of
the SASL process, then a tuning reset will occur.


> The design decision we made was to leave this kind of thing out, because
it can
> be implemented in the profiles, there did not appear to be a general
solution,
> and perhaps the greatest consideration was that it adds a lot of
complexity to the
> wrapper.

in the C and Tcl implementations, each data exchange profile is responsible
for determining whether the tuning is to its liking or not.

in the Java implementation, one could (as bill points out), have a subclass
of Profile that does the checking for you, so that the profile itself
doesn't have to check. seems like a fairly straight-forward abstraction to
put together.

however, at the present time, beepcore-java doesn't have that abstraction.

/mtr

Re: [Beepcore-java-users] Requireing a profile

[Kevin K. <kk...@my...>]

Resend.... Reply-to was wrong... OOPS.

see comments below....

--Kevin
-------

On Tue, 2002-08-06 at 12:38, Marshall Rose wrote:
> > A note on tuning profiles, SASL is a tuning profile that affects the
> session
> > state, but does not issue a tuning reset.
> 
> actually, this is not true. if a security layer is negotiated as a part of
> the SASL process, then a tuning reset will occur.
> 
> 
> > The design decision we made was to leave this kind of thing out, because
> it can
> > be implemented in the profiles, there did not appear to be a general
> solution,
> > and perhaps the greatest consideration was that it adds a lot of
> complexity to the
> > wrapper.
> 
> in the C and Tcl implementations, each data exchange profile is responsible
> for determining whether the tuning is to its liking or not.
> 
> in the Java implementation, one could (as bill points out), have a subclass
> of Profile that does the checking for you, so that the profile itself
> doesn't have to check. seems like a fairly straight-forward abstraction to
> put together.
> 
> however, at the present time, beepcore-java doesn't have that abstraction.
> 
> /mtr
> 

All,

I just wanted to point out that I am a newcomer to beep, and I am coming
to this after reading the RFC only 2 or 3 times, so I want to admit up
front I could be completely off base, but I figured I may as well try to
explore the idea.  Also if I am just rehashing something that has
already been discussed please let me know.

Throwing the responsibility of check dependencies to the parent class of
the TuningProfile is more along the lines of what I had in mind, but let
me put up and example that is a little more along the lines of what I
had in mind. 

This not in any way a real world example, but something I have come up
with to further discussion.  

for this example there exists 5 profiles (full URI's removed for
brevity)

- TLS
- SASL/ANONYMOUS
- SASL/OTP
- SASL/OTHER (one that negotiates both authentication and a security
layer)
- Some Application profile, lets say SMTP.


Now consider the following situations all implemented in different
software processes:

case 1:
SMTP requires SASL/OTP
SASL/OTP requires TLS

case 2:
SMTP requires SASL/ANONYMOUS

case 3:
SMTP requires SASL/OTHER

case 4:
SMTP requires nothing.

In each of these cases SMTP works exactly the same once the channel is
started, ie no change in functionality.  What I am proposing is that the
core functionality be written so that it can be aware of these different
dependencies and handle them, so the application writer does not have to
worry about them at a profile level, only at the session level.

Now in the case where the profile is aware of the authentication layers
that are sitting above it, the SMTP Profile (or its parent class) has to
check to see what encryption/authentication schemes are in place and
compare those to what it knows about.  This would require the session to
call to he profile and then the profile to veto the start channel until
proper authentication is in place.  

If this were setup at the session layer, the profile would be blissfully
unaware of what is running underneath it (unless that info is
specifically requested form the session).  It would be the job of the
session to determine whether a profile has enough
authentication/encryption/etc in place.  How would it determine this? 
The ProfileRegistry could be augmented to contain a dependency scheme. 
This could allow for both tuning and application profile dependencies. 
Say for a certain application you want to combine Echo profile with SMTP
(don't ask me why just an example), but that you do not want Echo to be
able to start unless a SMTP channel is already open.  Using dependencies
you could have attempts to start Echo fail until SMTP is up.

Here is where my ignorance of the details of BEEP comes in, are these
idea valid within the bounds of the specification.  From what I
understand for case 1 TLS should be the only protocol for the initial
greeting and SALS/OTP and SMTP come after that, but is it also legal to
advertise all 3 up front and have start requests to SASL/OTP and SMTP
error out?  Also if that is that is the case then should SMTP be
returning errorcode 530's before OTP is complete?  Should OTP be
throwing out errorCodes if TLS has not been started (534? 538? 550?)

Thanks for any comments.

--Kevin Kress

Re: [Beepcore-java-users] Requireing a profile

[Marshall R. <mr...@db...>]

hi. just a quick, non-responsive reply: it's perfectly fine to ask
questions, etc., and you won't be judged on your newness to the beep stuff.

i think there are several reasonable policies and abstractions that one
could configure to provide the functionality you're interested in (and it is
useful functionality).

/mtr

Re: [Beepcore-java-users] Requireing a profile

[Huston <hu...@us...>]

> All,
>
> I just wanted to point out that I am a newcomer to beep, and I am coming
> to this after reading the RFC only 2 or 3 times, so I want to admit up
> front I could be completely off base, but I figured I may as well try to
> explore the idea.  Also if I am just rehashing something that has
> already been discussed please let me know.
>
> Throwing the responsibility of check dependencies to the parent class of
> the TuningProfile is more along the lines of what I had in mind, but let
> me put up and example that is a little more along the lines of what I
> had in mind.
>
> This not in any way a real world example, but something I have come up
> with to further discussion.
>
> for this example there exists 5 profiles (full URI's removed for
> brevity)
>
> - TLS
> - SASL/ANONYMOUS
> - SASL/OTP
> - SASL/OTHER (one that negotiates both authentication and a security
> layer)
> - Some Application profile, lets say SMTP.
>
>
> Now consider the following situations all implemented in different
> software processes:
>
> case 1:
> SMTP requires SASL/OTP
> SASL/OTP requires TLS
>
> case 2:
> SMTP requires SASL/ANONYMOUS
>
> case 3:
> SMTP requires SASL/OTHER
>
> case 4:
> SMTP requires nothing.
>
> In each of these cases SMTP works exactly the same once the channel is
> started, ie no change in functionality.  What I am proposing is that the
> core functionality be written so that it can be aware of these different
> dependencies and handle them, so the application writer does not have to
> worry about them at a profile level, only at the session level.
>
> Now in the case where the profile is aware of the authentication layers
> that are sitting above it, the SMTP Profile (or its parent class) has to
> check to see what encryption/authentication schemes are in place and
> compare those to what it knows about.  This would require the session to
> call to he profile and then the profile to veto the start channel until
> proper authentication is in place.
>
> If this were setup at the session layer, the profile would be blissfully
> unaware of what is running underneath it (unless that info is
> specifically requested form the session).  It would be the job of the
> session to determine whether a profile has enough
> authentication/encryption/etc in place.  How would it determine this?
> The ProfileRegistry could be augmented to contain a dependency scheme.
> This could allow for both tuning and application profile dependencies.
> Say for a certain application you want to combine Echo profile with SMTP
> (don't ask me why just an example), but that you do not want Echo to be
> able to start unless a SMTP channel is already open.  Using dependencies
> you could have attempts to start Echo fail until SMTP is up.
>
> Here is where my ignorance of the details of BEEP comes in, are these
> idea valid within the bounds of the specification.  From what I
> understand for case 1 TLS should be the only protocol for the initial
> greeting and SALS/OTP and SMTP come after that, but is it also legal to
> advertise all 3 up front and have start requests to SASL/OTP and SMTP
> error out?  Also if that is that is the case then should SMTP be
> returning errorcode 530's before OTP is complete?  Should OTP be
> throwing out errorCodes if TLS has not been started (534? 538? 550?)

Yes you could return an error. I prefer not advertising the profile until
the minimum requirements that require tuning resets have been met (e.g.
encryption).

Support for this basic idea currently exist in the library between the
tuning properties in ProfileRegistry and the start channel listener code in
Session, but it could use some work. I think currently it returns 550 for
all error cases.

Another feature that was planned along this same line of thought is to also
be able to restrict starting a channel based on attributes for a given
tuning property (e.g. key length).

--Huston