qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clemens Vasters <cleme...@microsoft.com>
Subject RE: SASL negotiation w/ EXTERNAL
Date Wed, 09 Sep 2015 15:57:37 GMT
Hi Andrew,

I agree that the server should only offer EXTERNAL when the client has presented a valid cert.

We have the case that we still want to use PLAIN or ANONYMOUS even in that case, however,
since we'll want to use a particular permissions-bound key not representable by the cert,
or differentiated per-node (link) access control with the AMQP claims-based model, while also
making sure that the connecting client is authorized to make the connection in the first place.
The broker gateway handles the cert and we offer EXTERNAL, but the client then opts not to
use that identity but rather want to use CBS or a particular permissions-bound key.

So I/we would really like to have an override hook for this. The flags seem cheap; a    pn_messenger_set_allowed_sasl_mechs()
 function would be just as cheap. Advantage of the flag is that it integrates nicely with
flag that's already there. 

For the flags I've done the work and can send a PR. I also fixed the bug I filed yesterday
about pn_messenger_set_flags in one go as it's the same function.  

Best Regards

-----Original Message-----
From: Andrew Stitcher [mailto:astitcher@redhat.com] 
Sent: Mittwoch, 9. September 2015 16:58
To: proton@qpid.apache.org
Subject: Re: SASL negotiation w/ EXTERNAL

On Wed, 2015-09-09 at 09:27 +0000, Clemens Vasters wrote:
> Hi Qpid Proton,
> tl;dr: I'm working with Proton-C 0.10 and would like to have explicit 
> override options to keep Proton-C from automatically picking up on 
> EXTERNAL when being offered by the server - while using the messenger 
> layer.
> By what I can see, currently Proton-C's messenger automatically picks 
> up EXTERNAL as the default mechanism whenever offered by the server, 
> and when a username has been configured for the target URI. I believe 
> Proton-C s only needs to pick up on EXTERNAL under two explicit
> circumstances:

I'm going to assume that you are using the default implementation of SASL with Proton (as
I'm guessing you are using Windows), however the Cyrus SASL implementation behaviour should
be pretty much identical.

As you imply, the Proton SASL implementation has a preference for more secure authentication
where available over less secure authentication.

However it will only choose EXTERNAL iff there was a client certificate that the server authenticated

So if you are seeing EXTERNAL being chosen over PLAIN then you must have a valid client certificate
that the server accepted. Remember it is the server that is responsible for offering mechanisms.
If the server didn't accept the SSL client certificate it shouldn't have offered EXTERNAL.

The client will always choose EXTERNAL (by default) because it is a more secure option than

Using the pn_sasl_allow_mechs() API you can restrict which mechs a client (or server) will
consider using. However currently the messenger API has no easy way to use this API - this
would be a reasonable area for an API addition - although I'm not sure about simply introducing
new flags, there seems to be no end of them once started and it gets hard to figure out the
interactions between them pretty soon.

However fundamentally It seems to me that no server should offer EXTERNAL as a mechanism unless
the client *is already* authenticated via SSL. So if it is offered then they should be no
way for the client to select it and it fails. I'm pretty sure that this is the behaviour of
the Proton library with Cyrus SASL used as a server.

It could be that I am misunderstanding how SSL certificates work in this case, and it is definitely
possible there is a bug in the code as it runs on Windows, as I haven't tested client certificate
scenarios very much in that environment.


View raw message