beepcore-java-users

[Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76 - 8 msgs

[Darren N. <dn...@sa...>]

> > 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 problem comes when you add the requirement
  SMTP checks that the "From:" address belongs to the user 
  who logged in via SASL.

All of a sudden, you're back to having SMTP no longer blissfully unaware of
SASL any more.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76- 8 msgs

[Darren N. <dn...@sa...>]

Kevin Kress wrote:
> I am more interested in situations where the profile already exists and
> the application designer wishes to layer security/authentication under
> it.  This would allow the security layer to exist without the profile
> having to expressly know the security is there.

Right. This can already be done for TLS. Otherwise, you're saying everyone
with credentials on the server can run all the operations via this profile
identically. I don't think that's actually going to be too common.

Putting a call in the start routine that says "is my configuration flag set?
If so, is the user name non-empty? If so, go ahead" makes sense. The profile
is still going to have to generate a profile-specific message denying
permission to open the channel.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a T-bone steak
  walking into an all-you-can-eat seafood buffet.

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76- 8 msgs

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

On Tue, 2002-08-06 at 16:55, Darren New wrote:
> Kevin Kress wrote:
> > I am more interested in situations where the profile already exists and
> > the application designer wishes to layer security/authentication under
> > it.  This would allow the security layer to exist without the profile
> > having to expressly know the security is there.
>=20
> Right. This can already be done for TLS. Otherwise, you're saying everyon=
e
> with credentials on the server can run all the operations via this profil=
e
> identically. I don't think that's actually going to be too common.
>=20
> Putting a call in the start routine that says "is my configuration flag s=
et?
> If so, is the user name non-empty? If so, go ahead" makes sense. The prof=
ile
> is still going to have to generate a profile-specific message denying
> permission to open the channel.

So I guess it does make more sense to have a full set of utilities to
allow a profile to get as much information about the credentials and
encryption available (or active) in a session and then leave the rest up
to the profile.

.... OK I have another question that this discussion has raised.  When
exactly does a TuningProfile warrent a session reset and resending of
greetings?  Does it corresond only with the encoding change, in the
example of TLS?  Can any TuningProfile mandate a greeting exchange after
establishment as long as that is specified in the specification of the
profile?

Thanks,

--Kevin

Re: [Beepcore-java-users] Re: Beepcore-java-users digest, Vol 1 #76 - 8 msgs

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

Ok so maybe SMTP was not the best example for this, in the case I would
propose that the SMTP profile contacts the session and asks for the
session's credentials, which should include the username and password.

But with your example you are writing a requirement that explicitly
requires the profile to interact with the authentication system.

I am more interested in situations where the profile already exists and
the application designer wishes to layer security/authentication under
it.  This would allow the security layer to exist without the profile
having to expressly know the security is there.

--KMK

On Tue, 2002-08-06 at 16:18, Darren New wrote:
> > > 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 problem comes when you add the requirement
>   SMTP checks that the "From:" address belongs to the user 
>   who logged in via SASL.
> 
> All of a sudden, you're back to having SMTP no longer blissfully unaware of
> SASL any more.
> 
> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.
>    ** http://images.fbrtech.com/dnew/ **
> 
> They looked up at me like I was a T-bone steak
>   walking into an all-you-can-eat seafood buffet.
> 
> 
> -------------------------------------------------------
> 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