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