Re: Comments about draft-ietf-ldapbis-authmeth-06.txt

[Alexey Melnikov <Alexey.Melnikov@isode.com>]

Alexey Melnikov wrote:

> Roger Harrison wrote:
>
> > > 2).
> > > >4.2.3. TLS Connection Closure Effects
> > > >
> > > > Closure of the TLS session MUST cause the LDAP association to move
> > > > to an anonymous authentication and authorization state regardless of
> > > > the state established over TLS and regardless of the authentication
> > > > and authorization state prior to TLS session establishment.
> > >
> > > Ok, this was discussed before, so I might be missing some context.
> > > But is there any good reason for this?
> >  
> > This has been discussed before. Leaving the authorization state 
> > unchanged isn't feasible because it could open security holes (high 
> > level of authorization with lack of TLS protection). The best I can 
> > tell, there are really only two reasonable alternatives:
> >  
> > 1. restore the authorization state that existed just prior to 
> > initiation of TLS session establish
> > 2. go to anonymous authorization state
> >  
> > #1 may be difficult for servers to implement, so #2 was chosen as the 
> > default action.  It also guarantees a well-known state upon TLS closure.
>
>
> I think you should add the explanation you gave me to the document.
>
> The reason why I've asked this questions is as follows. Imagine that 
> the client used TLS and than authenticated using GSSAPI (Kerberos) or 
> DIGEST-MD5.
> Then the client decides to close TLS. Why is suddenly authentication 
> information is invalid, it wasn't derived from TLS information in the 
> first place?
> This is just an unexpected behavior. 

This reminded me:

1). LDAP has to state how TLS and SASL security layers are stacked.
2). When you close TLS, do you want to also remove a SASL security layer?
Usually a SASL security layer state is stored separately from the SASL 
authentication state, so you can keep it.
If you decide to remove it, you need to define at what point the data 
is no longer protected.

Cheers,

Alexey
__________________________________________
Isode Limited, http://www.isode.com

Cell: +44 7753759732

IETF standard related pages:
http://orthanc.ab.ca/mel/devel/Links.html

Personal Home Page: http://orthanc.ab.ca/mel
__________________________________________