You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Tony Blanchard <bl...@wanadoo.fr> on 2005/05/04 11:06:14 UTC

TLS + SASL external and ACLs.

Hi,

I am actually interested in using apacheDS with the features of TLS 
+SASL External and maybe ACLs.
As I looked to Jira, I did not find any issues on this in mina or direve.
Could someone tell me if there is someone working on it or planning to 
do so ?

If someone is working on it, where could I find some documents on the 
design for those futur functionnalities ?
If there is nobody working on it, maybe would I participate to it but I 
can not figure how as I am new to open source...
Should I create some issues in Jira and affect them to me ? How to 
debate on some design strategy or some integration needs with all the 
developpers ?

Thanks,
Tony Blanchard



Re: TLS + SASL external and ACLs.

Posted by Vinod Panicker <vi...@gmail.com>.
Hi Tony,

On 5/4/05, Tony Blanchard <bl...@wanadoo.fr> wrote:
> Hi,
> 
> I am actually interested in using apacheDS with the features of TLS
> +SASL External and maybe ACLs.
> As I looked to Jira, I did not find any issues on this in mina or direve.
> Could someone tell me if there is someone working on it or planning to
> do so ?

MINA does support TLS/SSL currently.  SASL support is currently not
there, but I'm, planning to implement SASL using the DIGEST-MD5
mechanism as a MINA filter soon.  Other mechanisms would also follow. 
I think I'll get around to this next week.

> If someone is working on it, where could I find some documents on the
> design for those futur functionnalities ?
> If there is nobody working on it, maybe would I participate to it but I
> can not figure how as I am new to open source...
> Should I create some issues in Jira and affect them to me ? How to
> debate on some design strategy or some integration needs with all the
> developpers ?

Trustin / Alex would be able to shed more light on this.  But as a
starting point i'd suggest that you go thru the mina docs.

Regards,
Vinod.

Re: TLS + SASL external and ACLs.

Posted by Tony Blanchard <bl...@wanadoo.fr>.
Thanks for all your answers Vinod. Thanks again for all people who 
participate to this thread.
I will look for the testcase you mentioned this week-end.

Thanks again for your job.
Best regards
Tony Blanchard

Vinod Panicker a écrit :

>Hi Tony,
>
>On 5/6/05, Tony Blanchard <bl...@wanadoo.fr> wrote:
>  
>
>>Sorry but I have another question for this thread.
>>
>>Someone told me that TLS was implemented in mina and I can not see
>>where. I just saw the SSL Filter.
>>Maybe I have missed something. Could someone tell me how it works briefly ?
>>    
>>
>
>TLS *is* implemented in MINA.  Basically with the new SSLEngine from
>Java 5, its possible to have both TLS and SSL.  If you look at the
>test cases for SSLFilter/SSLHandler, they use BogusSSLContextFactory
>for getting an object of the SSLContext.  If you see the source for
>BogusSSLContextFactory, the PROTOCOL is mentioned as TLS.  So
>actually, its using TLS right now.
>
>Regards,
>Vinod.
>
>PS: TLS 1.0 is also commonly (though semantically incorrectly)
>referred to as SSL 3.0
>
>
>
>  
>



Re: TLS + SASL external and ACLs.

Posted by Vinod Panicker <vi...@gmail.com>.
Hi Tony,

On 5/6/05, Tony Blanchard <bl...@wanadoo.fr> wrote:
> Sorry but I have another question for this thread.
> 
> Someone told me that TLS was implemented in mina and I can not see
> where. I just saw the SSL Filter.
> Maybe I have missed something. Could someone tell me how it works briefly ?

TLS *is* implemented in MINA.  Basically with the new SSLEngine from
Java 5, its possible to have both TLS and SSL.  If you look at the
test cases for SSLFilter/SSLHandler, they use BogusSSLContextFactory
for getting an object of the SSLContext.  If you see the source for
BogusSSLContextFactory, the PROTOCOL is mentioned as TLS.  So
actually, its using TLS right now.

Regards,
Vinod.

PS: TLS 1.0 is also commonly (though semantically incorrectly)
referred to as SSL 3.0

Re: TLS + SASL external and ACLs.

Posted by David Boreham <da...@bozemanpass.com>.
Alex Karasulu wrote:

> Dave looks like you have some extended experience with both Start TLS 
> and SASL.  How about taking this on for us :) ?

Sure, if we can find a funding source for these features.





Re: TLS + SASL external and ACLs.

Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:

>> BTW Can I get some pointers to StartTLS and SASL?  I don't know much 
>> about them.
>
> Start TLS : http://www.faqs.org/rfcs/rfc2830.html
> (Start TLS is easy: client sends a special extended op to the
> server that says 'after you send me a postitive response to
> this operation, flip the connection over to SSL/TLS').
> Start TLS is a mechanism for avoiding the need to listen
> on a separate port for SSL connections.
>
> SASL: http://www.ipnet6.org/src/cyrus-sasl-2/doc/
> (As we've seen, SASL is a rather complicated mult-functional
> thing. I've personally found it necessary to read the source
> code from the reference implementation in order to fully
> understand how to implement parts of it, because the
> RFCs are not 100% clear or complete).
> (Not all of the full SASL gamut is needed nor commonly used with
> LDAP).

Dave looks like you have some extended experience with both Start TLS 
and SASL.  How about taking this on for us :) ?

Alex


Re: TLS + SASL external and ACLs.

Posted by David Boreham <da...@bozemanpass.com>.
>
>
>
>BTW Can I get some pointers to StartTLS and SASL?  I don't know much about them.
>
>  
>
Start TLS : http://www.faqs.org/rfcs/rfc2830.html
(Start TLS is easy: client sends a special extended op to the
server that says 'after you send me a postitive response to
this operation, flip the connection over to SSL/TLS').
Start TLS is a mechanism for avoiding the need to listen
on a separate port for SSL connections.

SASL: http://www.ipnet6.org/src/cyrus-sasl-2/doc/
(As we've seen, SASL is a rather complicated mult-functional
thing. I've personally found it necessary to read the source
code from the reference implementation in order to fully
understand how to implement parts of it, because the
RFCs are not 100% clear or complete).
(Not all of the full SASL gamut is needed nor commonly used with
LDAP).




Re: TLS + SASL external and ACLs.

Posted by Trustin Lee <tr...@gmail.com>.
Hi,

2005/5/7, David Boreham <da...@bozemanpass.com>:
> 
> >>Trustin, wouldnt StartTLS be a part of the LDAP protocol impl rather
> >>than a MINA filter?  I'm talking abt the command impl, not the actual
> >>TLS handshake/encryption/decryption.  For this we already have the
> >>SSLFilter.
> To implement StartTLS you need to do two things:
> 
> 1. Decode the LDAP extended operation.
> 2. Tell the network I/O layer to install SSL/TLS on the connection
> and initiate its handshake.
>
> The existing filter should be fine, as long as the code that
> sees the extended operation has the ability to install the filter
> (and as long as filters can be installed on-the-fly on a
> connection that is already open).

I agree.  Adding SSLFilter globally won't work in case we implement StartTLS.

BTW Can I get some pointers to StartTLS and SASL?  I don't know much about them.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: TLS + SASL external and ACLs.

Posted by David Boreham <da...@bozemanpass.com>.
>>Trustin, wouldnt StartTLS be a part of the LDAP protocol impl rather
>>than a MINA filter?  I'm talking abt the command impl, not the actual
>>TLS handshake/encryption/decryption.  For this we already have the
>>SSLFilter.
>>
>>    
>>
To implement StartTLS you need to do two things:

1. Decode the LDAP extended operation.
2. Tell the network I/O layer to install SSL/TLS on the connection
and initiate its handshake.

The existing filter should be fine, as long as the code that
sees the extended operation has the ability to install the filter
(and as long as filters can be installed on-the-fly on a
connection that is already open).



Re: TLS + SASL external and ACLs.

Posted by Vinod Panicker <vi...@gmail.com>.
Hi,

On 5/6/05, Trustin Lee <tr...@gmail.com> wrote:
> 2005/5/6, David Boreham <da...@bozemanpass.com>:
> > Tony Blanchard wrote:
> >
--snip--
> 
> We didn't implement StartTLS yet.  I think we can't make it in 0.7
> release, but we'll provide most common filters at least in 0.8.
> 

Trustin, wouldnt StartTLS be a part of the LDAP protocol impl rather
than a MINA filter?  I'm talking abt the command impl, not the actual
TLS handshake/encryption/decryption.  For this we already have the
SSLFilter.

Regards,
Vinod.

Re: TLS + SASL external and ACLs.

Posted by Trustin Lee <tr...@gmail.com>.
2005/5/6, David Boreham <da...@bozemanpass.com>:
> Tony Blanchard wrote:
> 
> > Sorry but I have another question for this thread.
> >
> > Someone told me that TLS was implemented in mina and I can not see
> > where. I just saw the SSL Filter.
> > Maybe I have missed something. Could someone tell me how it works
> > briefly ?
> >
> Do you mean startTLS ?

We didn't implement StartTLS yet.  I think we can't make it in 0.7
release, but we'll provide most common filters at least in 0.8.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: TLS + SASL external and ACLs.

Posted by Tony Blanchard <bl...@wanadoo.fr>.
Yes.

David Boreham a écrit :

> Tony Blanchard wrote:
>
>> Sorry but I have another question for this thread.
>>
>> Someone told me that TLS was implemented in mina and I can not see 
>> where. I just saw the SSL Filter.
>> Maybe I have missed something. Could someone tell me how it works 
>> briefly ?
>>
> Do you mean startTLS ?
>
>
>
>
>



Re: TLS + SASL external and ACLs.

Posted by David Boreham <da...@bozemanpass.com>.
Tony Blanchard wrote:

> Sorry but I have another question for this thread.
>
> Someone told me that TLS was implemented in mina and I can not see 
> where. I just saw the SSL Filter.
> Maybe I have missed something. Could someone tell me how it works 
> briefly ?
>
Do you mean startTLS ?



Re: TLS + SASL external and ACLs.

Posted by Tony Blanchard <bl...@wanadoo.fr>.
Sorry but I have another question for this thread.

Someone told me that TLS was implemented in mina and I can not see 
where. I just saw the SSL Filter.
Maybe I have missed something. Could someone tell me how it works briefly ?

Thanks
Tony Blanchard

Vinod Panicker a écrit :

>Hi,
>
>On 5/5/05, Chris Betts <ch...@pegacat.com> wrote:
>  
>
>>Hi Folks,
>>
>>    I'm utterly ignorant about SASL at the server end, but at the client
>>end all I had to do was write my own ssl socket factory (just extending
>>the default Sun version) and manually feed it the client cert + key.
>>At the server end can you do the same sort of trick in reverse and
>>eavesdrop on the exchange to get the client certificate, and then use
>>that to authenticate?  I guess I'm only thinking of the SASL external
>>certificate authentication - I don't know about the other versions...
>>
>>    
>>
>
>Basically the Java SASL framework allows registration of callback
>handlers et al.  If the EXTERNAL mechanism is being used, there would
>be a way to get the client credentials from the lower layers
>(TLS/SSL).  Refer to section 9 of RFC 2829 and section 7.4 of RFC 2222
>for more info.
>
>--snip--
>
>Regards,
>Vinod.
>
>
>
>  
>



Re: TLS + SASL external and ACLs.

Posted by Vinod Panicker <vi...@gmail.com>.
Hi,

On 5/5/05, Chris Betts <ch...@pegacat.com> wrote:
> Hi Folks,
> 
>     I'm utterly ignorant about SASL at the server end, but at the client
> end all I had to do was write my own ssl socket factory (just extending
> the default Sun version) and manually feed it the client cert + key.
> At the server end can you do the same sort of trick in reverse and
> eavesdrop on the exchange to get the client certificate, and then use
> that to authenticate?  I guess I'm only thinking of the SASL external
> certificate authentication - I don't know about the other versions...
> 

Basically the Java SASL framework allows registration of callback
handlers et al.  If the EXTERNAL mechanism is being used, there would
be a way to get the client credentials from the lower layers
(TLS/SSL).  Refer to section 9 of RFC 2829 and section 7.4 of RFC 2222
for more info.

--snip--

Regards,
Vinod.

Re: TLS + SASL external and ACLs.

Posted by Chris Betts <ch...@pegacat.com>.
Hi Folks,

    I'm utterly ignorant about SASL at the server end, but at the client 
end all I had to do was write my own ssl socket factory (just extending 
the default Sun version) and manually feed it the client cert + key.  
At the server end can you do the same sort of trick in reverse and 
eavesdrop on the exchange to get the client certificate, and then use 
that to authenticate?  I guess I'm only thinking of the SASL external 
certificate authentication - I don't know about the other versions...

     Like I say though, I don't know much about the server side of these 
things :-)

    - Chris



>
> Alex, the caveat is that sasl in Java is only provided since 1.5.  If
> you are looking at 1.4 support, there might be other third party
> implementations, but I'm currently not aware of them.
>
> Regards,
> Vinod.
> --snip--
>


Re: TLS + SASL external and ACLs.

Posted by Vinod Panicker <vi...@gmail.com>.
Hi,

On 5/4/05, Alex Karasulu <ao...@bellsouth.net> wrote:
> Tony Blanchard wrote:
> 
> Hi Tony and welcome,
> 
--snip--
> 
> At this point we're trying to add as many features as we can and as fast
> as we can.  However it is nice to have some more help and support.  From
> the sound of it Vinod might have the SASL groked sooner rather than
> later and TLS is done.  These guys are doing an excellent job on working
> the network layer code.
> 

Alex, the caveat is that sasl in Java is only provided since 1.5.  If
you are looking at 1.4 support, there might be other third party
implementations, but I'm currently not aware of them.

Regards,
Vinod.
--snip--

Re: TLS + SASL external and ACLs.

Posted by Alex Karasulu <ao...@bellsouth.net>.
Tony Blanchard wrote:

Hi Tony and welcome,

> I am actually interested in using apacheDS with the features of TLS 
> +SASL External and maybe ACLs.
> As I looked to Jira, I did not find any issues on this in mina or direve.
> Could someone tell me if there is someone working on it or planning to 
> do so ?

At this point we're trying to add as many features as we can and as fast 
as we can.  However it is nice to have some more help and support.  From 
the sound of it Vinod might have the SASL groked sooner rather than 
later and TLS is done.  These guys are doing an excellent job on working 
the network layer code. 

The ACLs have not yet been implemented actually.  If I get a chance my 
next primary goal is just that.  However other things need to be 
implemented first like subentries which hold ACL information as well as 
other authoritative info.  To do subentries we need to be able to define 
other schema constructs like subtree specifications and their fast 
interpretation.  We're talking a little while out.

> If someone is working on it, where could I find some documents on the 
> design for those futur functionnalities ?

There is no design just yet for implementing ACLs.  I don't know if 
others have thought about this.  I have a few thoughts in my head but 
that's about it.  I should get it into wiki soon so people like yourself 
can ask questions and perhaps shed more light.

> If there is nobody working on it, maybe would I participate to it but 
> I can not figure how as I am new to open source...
> Should I create some issues in Jira and affect them to me ? How to 
> debate on some design strategy or some integration needs with all the 
> developpers ?

Even if there is no Jira on ACLs its a big concern as you may imagine.  
You can file a Jira no problem just do your best to make sure what ever 
Jira you create is not a duplicate but dups happen somethimes so don't 
worry.  In terms of debate just feel free to post your view point or 
your idea to this list.  We have a user list for user type question but 
feel free to keep those on this list too.   I don't think our traffic 
dev has hit the rate where it is a serious concern at the moment.

Cheers,
Alex