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 

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 

Best Regards

-----Original Message-----
From: Andrew Stitcher [mailto:astitc...@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 already.

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 PLAIN.

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.


Reply via email to