You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Vinod Panicker <vi...@gmail.com> on 2005/05/05 14:30:47 UTC
[mina] SASL support
Hi,
Basically got to thinking on this and realized that it wouldn't be
proper if SASL support is integrated into MINA. SASL is supposed to
be utilized by existing protocols as a means of providing
authentication. Its not an independent protocol in itself. In the
case of ApacheDS, the LDAP protocol would be carrying SASL data as
well. So actually SASL should be implemented by the ProtocolHandler
rather than as a MINA filter.
Regards,
Vinod.
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
>>
> It was what I meant by saying "Server layer to tell the client what
> mechanisms it handles".
Ah, ok. Then there's more: the server has to tell SASL which mechanisms
to expose
in the handshake, and then it has to get involved with authId and
authzId mapping.
> As Vinod said he can not work on it for the moment, maybe can I help
> him to model some classes to handle SASL. This is just a question of
> time...
> I need to discover the model used in asn1 and in the server projects
> to figure out a solution.
Like I said before, if you read the source for one or more existing sasl
implementations
much of this will become quite clear.
Re: [mina] SASL support
Posted by Tony Blanchard <bl...@wanadoo.fr>.
David Boreham a écrit :
> Tony Blanchard wrote:
>
>> If I do no make mistakes, I think there is three layer for SASL
>> (EXTERNAL is the only one i have looked for) implementation.
>>
>> 1- Server layer to tell the client what mechanisms it handles and to
>> provide some checkings regarding policy versus client asked mechanism.
>> 2- Mina layer to give TLS support and to give some acces to the
>> principal created and returned for this transport layer.
>> 3- LDAP protocol to engage the handshaking.LDAP v3 RFC 2251contains
>> some asn1 rules about request and response formats for sasl mechanisms .
>>
>> Am I wrong ?
>
>
> Nope.
>
> You also need stuff in the server to implement supportedSaslMechanisms
> in the root dse.
>
>
>
>
It was what I meant by saying "Server layer to tell the client what
mechanisms it handles".
As Vinod said he can not work on it for the moment, maybe can I help him
to model some classes to handle SASL. This is just a question of time...
I need to discover the model used in asn1 and in the server projects to
figure out a solution.
I will come back on this later.
Tony Blanchard
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
Tony Blanchard wrote:
> If I do no make mistakes, I think there is three layer for SASL
> (EXTERNAL is the only one i have looked for) implementation.
>
> 1- Server layer to tell the client what mechanisms it handles and to
> provide some checkings regarding policy versus client asked mechanism.
> 2- Mina layer to give TLS support and to give some acces to the
> principal created and returned for this transport layer.
> 3- LDAP protocol to engage the handshaking.LDAP v3 RFC 2251contains
> some asn1 rules about request and response formats for sasl mechanisms .
>
> Am I wrong ?
Nope.
You also need stuff in the server to implement supportedSaslMechanisms
in the root dse.
Re: [mina] SASL support
Posted by Tony Blanchard <bl...@wanadoo.fr>.
If I do no make mistakes, I think there is three layer for SASL
(EXTERNAL is the only one i have looked for) implementation.
1- Server layer to tell the client what mechanisms it handles and to
provide some checkings regarding policy versus client asked mechanism.
2- Mina layer to give TLS support and to give some acces to the
principal created and returned for this transport layer.
3- LDAP protocol to engage the handshaking.LDAP v3 RFC 2251contains some
asn1 rules about request and response formats for sasl mechanisms .
Am I wrong ?
Tony Blanchard
Vinod Panicker a écrit :
>Hi,
>
>Basically got to thinking on this and realized that it wouldn't be
>proper if SASL support is integrated into MINA. SASL is supposed to
>be utilized by existing protocols as a means of providing
>authentication. Its not an independent protocol in itself. In the
>case of ApacheDS, the LDAP protocol would be carrying SASL data as
>well. So actually SASL should be implemented by the ProtocolHandler
>rather than as a MINA filter.
>
>Regards,
>Vinod.
>
>
>
>
>
Re: [mina] SASL support
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
I'm sorry for late reply. It was Korean national holiday, so I spent
today with my family.
2005/5/5, Vinod Panicker <vi...@gmail.com>:
> Hi,
>
> Basically got to thinking on this and realized that it wouldn't be
> proper if SASL support is integrated into MINA. SASL is supposed to
> be utilized by existing protocols as a means of providing
> authentication. Its not an independent protocol in itself. In the
> case of ApacheDS, the LDAP protocol would be carrying SASL data as
> well. So actually SASL should be implemented by the ProtocolHandler
> rather than as a MINA filter.
ProtocolHandler or IoHandler can interact in three ways:
1. ProtocolHandler and IoHandler can get an instance of filter by
calling getFilterChain().get('filterName'). So you can call
filter-specific methods directly to control its behavior.
2. Filters can get some predefined session attributes that can be
initialized in sessionCreated(...) method.
3. Filters can define an interface with filter-specific event handler
methods. Any ProtocolHandler implementations that also implement that
interface will get notified by the filter. For example:
public class MyHandler implements IoHandler, SASLHandler {
...
public void saslEvent(SASLSession session, SASLEvent e) {
// ....
}
}
public class SASLFilter implement IoFilter {
public void dataRead(...) {
IoHandler handler = session.getHandler();
if( handler instanceof SASLHandler ) {
(SASLHandler) handler).saslEvent(...);
}
}
}
But this way is not perfect because IoFilters cannot get
ProtocolHandler which is backed by internal IoHandler implementation.
I don't know SASL, so I can say only general stuffs for now.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
BTW, SSL isn't totally independent and opaque either : you need to
make the cert payload available to the LDAP server in
order that it can perform cert-based auth. And the server
will need to know that the client's transport session is
SSL in order to enforce transport-type access control
(e.g. no mods to passwords accepted unless the client is connected
via SSL).
Clean layering is a fine objective, but sometimes one
needs to make software that works too ;)
Re: [mina] SASL support
Posted by Alex Karasulu <ao...@bellsouth.net>.
Vinod Panicker wrote:
>Hi,
>
>Basically got to thinking on this and realized that it wouldn't be
>proper if SASL support is integrated into MINA. SASL is supposed to
>be utilized by existing protocols as a means of providing
>authentication.
>
Right and the underlying protocol must be aware of the mechanism. LDAP
has to be. I guess it was just more wishful thinking that we could have
a MINA filter handle all cases.
>Its not an independent protocol in itself. In the
>case of ApacheDS, the LDAP protocol would be carrying SASL data as
>well. So actually SASL should be implemented by the ProtocolHandler
>rather than as a MINA filter.
>
>
I agree there is no way around it.
Alex
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
> Eeeek Cyrus SASL :).
ACK. But you will find that to achieve interoperability with SASL encryption
and Kerberos, it will help to read their source because there is no
complete
written specification for what you're supposed to send on the wire. The RFCs
become rather 'abstract' in this area, presumably because nobody had
actually
written any working code at the time they wrote the text.
Re: [mina] SASL support
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
> Vinod Panicker wrote:
>
>> Hi,
>>
>> Basically got to thinking on this and realized that it wouldn't be
>> proper if SASL support is integrated into MINA.
>
<snip/>
> Actually I don't think so. There are two aspects to SASL:
> authentication and 'encryption'. What you are saying is correct
> for the authentication part : for example in the case of LDAP
> the SASL payload is sent inside the regular BIND request PDU.
Yah I think Vinod was referring to the fact that you can't do it all
within the Filter. The protocol must be aware that some SASL mech is in
effect. As you say the LDAP implementation has to know the SASL
mechanism and support it. The Filter cannot do this on its behalf.
> However, for 'sasl encryption' the actual packets sent on the wire
> are wrapped by an encryption layer in much the same way as
> SSL. In implementing this it is necessary to get at the raw byte
> stream from the socket. To me this looks exactly like task for a mina
> filter.
This part yes think we would all agree can be made independent of protocol.
<snip/>
> See the Cyrus SASL kerberos plugin source code for more
> details on this.
Eeeek Cyrus SASL :).
Alex
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
>
>I guess we've been talking abt different things all this while.
>You've been talking abt the optionally negotiated security layer and
>i've been talking abt the actual sasl payload (challenges/responses).
>
>
Yes ! I had hoped that I'd made this clear a while back. Apologies for that.
>I'd be doing an SASL impl with DIGEST-MD5 and EXTERNAL mechanisms in
>this week for XMPP. These mechanisms do not have an optional security
>layer as the GSSAPI and Kerberos mechanisms do. I've already done an
>SASL poc using jdk 1.5 and the DIGEST-MD5 mechanism.
>
>
The DIGEST-MD5 mechanism _does_ support privacy and integrity
using exactly the same layering design as does gssapi (for LDAP at any
rate).
You can see the details of this in http://www.faqs.org/rfcs/rfc2831.html
(sections 2.3 and 2.4).
Microsoft implements this in AD, and so does Sun in their LDAP server.
Since it's support in Cyrus Sasl, a suitably built OpenLDAP would also
support MD5 with encryption. I've pasted a tiny bit of the Cyrus md5
plugin source code below for the unbelievers.
EXTERNAL does not have encryption, since it is designed for use with SSL,
encryption would be redundant.
>If the encryption is at a transport level, such as is with TLS/SSL, it
>would make great sense to implement a mina filter. But the question
>since the beginning has been -
>
>Where would you handle the SASL challenge/responses?
>
>
They get picked up inside the processing of the LDAP BIND request.
So you need to enhance that code (the challenge/response payload
is inside the BER for the BIND request and BIND response).
Typically from there there is yet another abstraction interface which
one calls with the payload, suitably unpacked from the BER.
Said interface has provisions to supply payload back to the caller,
and also to inform the caller if the authentication has succeeded,
_and_ when and if to install a security layer ;)
And on and on...
-------
/* if privacy mode is used use these functions for encode and decode */
cipher_function_t *cipher_enc;
cipher_function_t *cipher_dec;
cipher_init_t *cipher_init;
cipher_free_t *cipher_free;
struct cipher_context *cipher_enc_context;
struct cipher_context *cipher_dec_context;
} context_t;
struct digest_cipher {
char *name;
sasl_ssf_t ssf;
int n; /* bits to make privacy key */
int flag; /* a bitmask to make things easier for us */
cipher_function_t *cipher_enc;
cipher_function_t *cipher_dec;
cipher_init_t *cipher_init;
cipher_free_t *cipher_free;
};
Re: [mina] SASL support
Posted by Vinod Panicker <vi...@gmail.com>.
On 5/7/05, David Boreham <da...@bozemanpass.com> wrote:
>
> >>
> >> 4 - parse the application protocol so it can get the SASL payload
> >
> It occurred to me that this might be why you're confused about this.
> In the case of LDAP, your statment above is incorrect (I don't know
> anything about SASL with other protocols, so you may well be correct in non-LDAP cases).
> With LDAP, SASL encryption is layered _below_ the application procotol.
> That is, the encryption is done on the LDAP PDU byte stream,
> potentially with framing that is not aligned with the LDAP PDUs.
> It's essentially identically the same layering scenario as SSL/TLS.
> And this is why I will not be eating my keyboard regardless of how tasty
> it might be.
>
> (The SASL _authentication_ payload is carried in the LDAP protocol,
> within the BIND requests and responses, but _encryption_ is done below
> the LDAP protocol).
I guess we've been talking abt different things all this while.
You've been talking abt the optionally negotiated security layer and
i've been talking abt the actual sasl payload (challenges/responses).
I'd be doing an SASL impl with DIGEST-MD5 and EXTERNAL mechanisms in
this week for XMPP. These mechanisms do not have an optional security
layer as the GSSAPI and Kerberos mechanisms do. I've already done an
SASL poc using jdk 1.5 and the DIGEST-MD5 mechanism.
If the encryption is at a transport level, such as is with TLS/SSL, it
would make great sense to implement a mina filter. But the question
since the beginning has been -
Where would you handle the SASL challenge/responses?
Regards,
Vinod.
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
>>
>> 4 - parse the application protocol so it can get the SASL payload
>
It occurred to me that this might be why you're confused about this.
In the case of LDAP, your statment above is incorrect (I don't know
anything about
SASL with other protocols, so you may well be correct in non-LDAP cases).
With LDAP, SASL encryption is layered _below_ the application procotol.
That is, the encryption is done on the LDAP PDU byte stream,
potentially with framing that is not aligned with the LDAP PDUs.
It's essentially identically the same layering scenario as SSL/TLS.
And this is why I will not be eating my keyboard regardless of how tasty
it might be.
(The SASL _authentication_ payload is carried in the LDAP protocol,
within the BIND requests and responses, but _encryption_ is done below
the LDAP protocol).
As I've said a few times already, a quick read of some code that
implements this will show how it works.
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
>1 - support different mechanisms such as EXTERNAL, DIGEST-MD5, GSSAPI,
>KERBEROS etc.
>2 - provide encryption support as desired by each mechanism
>3 - provide facility to negotiate an optional security layer after
>authentication is done
>4 - parse the application protocol so it can get the SASL payload
>5 - support/decline multiple authentications per session depending on
>the application protocol in use
>
>
I don't quite know where you're going with this, but it seems clear that you
haven't implemented this before (I have, BTW).
Anyway, I don't care one way or the other what you do because
right now I have no need for any SASL support in Apache DS.
All I've been trying to say in this thread is that the assertion that
a filter is not required in order to implement SASL is false (at least
in the case that support for encryption is required).
Re: [mina] SASL support
Posted by Vinod Panicker <vi...@gmail.com>.
Hi David,
On 5/6/05, David Boreham <da...@bozemanpass.com> wrote:
> Vinod Panicker wrote:
>
--snip--
> >
> Unfortunately 'sasl' means many things.
> However, there certainly is encryption defined in RFC2222 for the GSSAPI
> mechansim
> and it's in common use in the wild (RFC2222 calls it the 'security layer').
Yes, encryption is defined in the Kerberos, GSSAPI "mechanisms".
The Security Layer of "Simple Authentication and Security Layer"
refers to an optional security layer that can be inserted after
authentication is completed for exchanging the protocol data.
> If you ever come to implement it for LDAP in Apache DS, I will eat my
> keyboard if you
> do not end up writing a mina filter.
I sure hope you have a tasty keyboard :)
But its starting to seem to me that we are talking abt different
things. Lets take a different approach. Lets assume that we do
implement an SASL filter in MINA. In that case, the filter would need
to -
1 - support different mechanisms such as EXTERNAL, DIGEST-MD5, GSSAPI,
KERBEROS etc.
2 - provide encryption support as desired by each mechanism
3 - provide facility to negotiate an optional security layer after
authentication is done
4 - parse the application protocol so it can get the SASL payload
5 - support/decline multiple authentications per session depending on
the application protocol in use
If you agree with the above, we can have a poll on this.
> You are correct that the specific
> relationship between
> the security layer PDUs and the transport do depend on the application
> protocol in use.
> My comments in this thread have been in the context of LDAP as the
> application protocol.
Also, MINA needs to be able to work with different application layer protocols.
--snip--
Regards,
Vinod.
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
Well your attachment nearly broke my mail client and I couldn't
read it ;)
So, SASL-EXTERNAL is almost a no-op.
Basically you just need to spot the case in the bind operation
processing code
and then ask the SSL layer for the client cert content.
Then you need to do whatever you fancy doing with that
information to determine bind identity and whether or not to allow the bind.
AFAIK none of the above is implemented already , but it's
not particularly hard or big a job.
Re: [mina] SASL support
Posted by Tony Blanchard <bl...@wanadoo.fr>.
Here is a "summary" of what I understood from the different RFCs for the
SASL External authentication mechanism based on TLS. See the joined
piece of file.
If I made errors on this sequence, please tell me.
The question is to know what already exists in apacheDS and what does not.
After that, we will know what is to be done to achieve this functionnality.
Best regards
Tony Blanchard
Answers to this message are not urgent so feel free to postpone it.
David Boreham a écrit :
> Vinod Panicker wrote:
>
>> There is no "encryption" aspect to SASL. SASL simply acts as a
>> container or as a definition of a challenge-response technique for
>> authentication. The actual authentication is implemented by
>> mechanisms. SASL was designed to be extensible - that is why there
>> are many different mechanisms that are available today. Encryption as
>> a function would be specific to a mechanism. Even I can define a new
>> mechanism tomorrow and have the data being transmitted over the wire
>> encrypted. IMHO, the implementation of encryption/any other
>> functionality should be done within a mechanism. It would be wrong to
>> state that this functionality is part of "SASL" - its part of a
>> "Mechanism". Refer to http://www.iana.org/assignments/sasl-mechanisms
>> for a list of all registered SASL mechanisms.
>>
>>
> Unfortunately 'sasl' means many things.
> However, there certainly is encryption defined in RFC2222 for the
> GSSAPI mechansim
> and it's in common use in the wild (RFC2222 calls it the 'security
> layer').
> If you ever come to implement it for LDAP in Apache DS, I will eat my
> keyboard if you
> do not end up writing a mina filter. You are correct that the specific
> relationship between
> the security layer PDUs and the transport do depend on the application
> protocol in use.
> My comments in this thread have been in the context of LDAP as the
> application protocol.
>
> There is also encryption defined in RFC 2831 for the digest mechanism.
>
> See the functions sasl_encode() and sasl_decode() (notice not
> mechansism-specific)
> in Cyrus-SASL, and the file sasl_layer.c in OpenLDAP for more
> inspiration.
>
>
>
>
>
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
Vinod Panicker wrote:
>There is no "encryption" aspect to SASL. SASL simply acts as a
>container or as a definition of a challenge-response technique for
>authentication. The actual authentication is implemented by
>mechanisms. SASL was designed to be extensible - that is why there
>are many different mechanisms that are available today. Encryption as
>a function would be specific to a mechanism. Even I can define a new
>mechanism tomorrow and have the data being transmitted over the wire
>encrypted. IMHO, the implementation of encryption/any other
>functionality should be done within a mechanism. It would be wrong to
>state that this functionality is part of "SASL" - its part of a
>"Mechanism". Refer to http://www.iana.org/assignments/sasl-mechanisms
>for a list of all registered SASL mechanisms.
>
>
Unfortunately 'sasl' means many things.
However, there certainly is encryption defined in RFC2222 for the GSSAPI
mechansim
and it's in common use in the wild (RFC2222 calls it the 'security layer').
If you ever come to implement it for LDAP in Apache DS, I will eat my
keyboard if you
do not end up writing a mina filter. You are correct that the specific
relationship between
the security layer PDUs and the transport do depend on the application
protocol in use.
My comments in this thread have been in the context of LDAP as the
application protocol.
There is also encryption defined in RFC 2831 for the digest mechanism.
See the functions sasl_encode() and sasl_decode() (notice not
mechansism-specific)
in Cyrus-SASL, and the file sasl_layer.c in OpenLDAP for more inspiration.
Re: [mina] SASL support
Posted by Vinod Panicker <vi...@gmail.com>.
OK, here's the explanation that I promised.
On 5/5/05, David Boreham <da...@bozemanpass.com> wrote:
> Vinod Panicker wrote:
>
--snip
> Actually I don't think so. There are two aspects to SASL:
> authentication and 'encryption'. What you are saying is correct
> for the authentication part : for example in the case of LDAP
> the SASL payload is sent inside the regular BIND request PDU.
There is no "encryption" aspect to SASL. SASL simply acts as a
container or as a definition of a challenge-response technique for
authentication. The actual authentication is implemented by
mechanisms. SASL was designed to be extensible - that is why there
are many different mechanisms that are available today. Encryption as
a function would be specific to a mechanism. Even I can define a new
mechanism tomorrow and have the data being transmitted over the wire
encrypted. IMHO, the implementation of encryption/any other
functionality should be done within a mechanism. It would be wrong to
state that this functionality is part of "SASL" - its part of a
"Mechanism". Refer to http://www.iana.org/assignments/sasl-mechanisms
for a list of all registered SASL mechanisms.
>
> However, for 'sasl encryption' the actual packets sent on the wire
> are wrapped by an encryption layer in much the same way as
> SSL. In implementing this it is necessary to get at the raw byte
> stream from the socket. To me this looks exactly like task for a mina
> filter.
Disagree. The SASL payload is supposed to be carried by the host
protocol, which can have its own way of defining how it will carry the
SASL payload. It basically has to provide a conduit for the SASL
challenges/responses. SSL is different in the sense that its at the
Transport layer. The SASL payload is carried by an Application layer
protocol. Its not necessary to get the raw byte stream since the
carrier protocol might state that the SASL payload has to be encoded
in a certain format - eg base64. Here, the SASL data would be sent as
ASCII text.
>
> Now, it turns out that not many deployed apps actually use
> sasl encryption. The one I'm most familiar with is Kerberos.
> i.e. if you initiate an LDAP session with SASL and the Kerberos
> mechansim, you can negotiate encryption using SASL, which
> actually ends up being done by Kerberos. Same goes I believe
> for at least one of the MD5-based mechanisms.
>
> Quite a few existing LDAP servers support SASL encryption, FWIW.
>
> See the Cyrus SASL kerberos plugin source code for more
> details on this.
>
TLS is the perfect candidate for a MINA filter since it will
manipulate *all* data being sent over the wire. An SASL mechanism
requiring encryption isnt coz the carrier protocol might define a
specific method of wrapping it. MINA has to be protocol agnostic.
Also, the SASL sequence comes into play usually only once for a user
session, whereas a filter is designed to be for a longer period -
mostly for the entire session.
Hope this makes it clear as to why having an SASL filter in MINA would
be a bad design decision.
Regards,
Vinod.
Re: [mina] SASL support
Posted by Vinod Panicker <vi...@gmail.com>.
Will be replying to this thread in detail as to why SASL *cannot* be a
MINA filter. Very busy with some things now. I've gone thru the SASL
grind once, so I do know something abt it.
Regards,
Vinod.
--snip--
Re: [mina] SASL support
Posted by David Boreham <da...@bozemanpass.com>.
Vinod Panicker wrote:
>Hi,
>
>Basically got to thinking on this and realized that it wouldn't be
>proper if SASL support is integrated into MINA. SASL is supposed to
>be utilized by existing protocols as a means of providing
>authentication. Its not an independent protocol in itself. In the
>case of ApacheDS, the LDAP protocol would be carrying SASL data as
>well. So actually SASL should be implemented by the ProtocolHandler
>rather than as a MINA filter.
>
>
Actually I don't think so. There are two aspects to SASL:
authentication and 'encryption'. What you are saying is correct
for the authentication part : for example in the case of LDAP
the SASL payload is sent inside the regular BIND request PDU.
However, for 'sasl encryption' the actual packets sent on the wire
are wrapped by an encryption layer in much the same way as
SSL. In implementing this it is necessary to get at the raw byte
stream from the socket. To me this looks exactly like task for a mina
filter.
Now, it turns out that not many deployed apps actually use
sasl encryption. The one I'm most familiar with is Kerberos.
i.e. if you initiate an LDAP session with SASL and the Kerberos
mechansim, you can negotiate encryption using SASL, which
actually ends up being done by Kerberos. Same goes I believe
for at least one of the MD5-based mechanisms.
Quite a few existing LDAP servers support SASL encryption, FWIW.
See the Cyrus SASL kerberos plugin source code for more
details on this.