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
|
