You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Clemens Vasters <cl...@microsoft.com> on 2015/09/09 11:27:31 UTC
SASL negotiation w/ EXTERNAL
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:
a) As Proton is immediately responsible for establishing the TLS connection, snapping to EXTERNAL with TLS only appears to makes sense when Proton has been configured with an explicit TLS credential and has used that credential successfully. The EXTERNAL handshake subsequently binds the certificate identity used at the transport layer to the application layer, i.e. the two identities ought be deemed identical by the server for proceeding past the handshake.
b) Alternatively, there might be some form of secure IPSec/VPN/etc tunnel that establishes the client identity with the server below the transport, in which case, by the way, the "allow insecure mechanisms" flag that has been introduced is making an incorrect implication as the tunnel provides security for a non-TLS PLAIN flow. In the case of such a tunnel, Proton should have to be configured with an explicit external identity before it picks up on EXTERNAL. Right now, EXTERNAL being offered and a configured sasl->username (which might have been intended to be part of a PLAIN credential set) seem sufficient to trigger snapping to EXTERNAL.
Thus, ideally, Proton's messenger would thus only snap to EXTERNAL if I have either set a transport credential (cert) or have explicitly set an external identity (distinct from the username used for PLAIN) for the second case.
Irrespective of whether that behavior ends up being automatic, it would be very useful to have an explicit override in Messenger to force either PLAIN or ANONYMOUS even if EXTERNAL has been offered up, so that the application protocol credential can differ from the transport credential, if so desired. The SASL layer allows me to do that with pn_sasl_allowed_mechs(). Unfortunately, Messenger doesn't give me a hook to set that from the outside, or at least it's not obvious if it were.
I've played with adding two PN_FLAGS_FORCE_SASL_PLAIN / PN_FLAGS_FORCE_SASL_ANONYMOUS extension flags for messenger; that works just fine, even though I don't like mutually exclusive options in flag fields. These flags beat introducing a new function, though.
The ANONYMOUS override is an escape hatch that allows opting for AMQP claims-based-security flow, ignoring any SASL mechanisms offered up by the server.
Snippet (3 similar looking spots in messenger.c) :
if (messenger->flags & (PN_FLAGS_ALLOW_INSECURE_MECHS |
PN_FLAGS_FORCE_SASL_PLAIN |
PN_FLAGS_FORCE_SASL_ANONYMOUS)) {
pn_sasl_t *s = pn_sasl(transport);
if (messenger->flags & PN_FLAGS_ALLOW_INSECURE_MECHS &&
user && pass)
{
pn_sasl_set_allow_insecure_mechs(s, true);
}
if (messenger->flags & PN_FLAGS_FORCE_SASL_PLAIN)
{
pn_sasl_allowed_mechs(s, "PLAIN");
}
if (messenger->flags & PN_FLAGS_FORCE_SASL_ANONYMOUS)
{
pn_sasl_allowed_mechs(s, "ANONYMOUS");
}
}
The override flags addition doesn't get into the automated selection options mentioned above, but is absolutely sufficient to unblock my scenarios.
Best Regards
Clemens
Clemens Vasters
Architect, Azure Service Bus
Microsoft Corporation
clemensv@microsoft.com<ma...@microsoft.com>
Twitter @clemensv
Re: AW: AW: SASL negotiation w/ EXTERNAL
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2015-09-16 at 16:34 +0000, Clemens Vasters wrote:
> ...
> The current behavior of Service Bus of offering up EXTERNAL in spite
> of not having gotten and verified a client credential at the TLS
> level not correct, and we've identified that as a bug on our side in
> the process of digging through this.
>
Interop testing of all kinds is pretty good at flushing out these sorts
of issues.
> Would the acceptable fix have to plumb the new API through all
> bindings?
By acceptable fix do you mean add pn_messenger_allow_sasl_mechs()? Or
something else?
The Proton SASL API has been designed to "just work" in as many cases
as possible, with only a few extra API hooks to configure it. I believe
that he underlying Proton engine API has all the necessary hooks and so
any new API binding should have them too.
The messenger API is special in that it insulates its use from the
engine to a large extent and doesn't really expose the transport (and
hence SASL) details. I had hoped that I wouldn't need to add SASL
functionality to the messenger API itself, but it seems that for
interop reasons such as this issue, it is necessary. So after adding
this new API any bindings of the messenger API will also get the new
API.
I'm not sure if that answers your question, as I'm not 100% sure what
the question was.
Andrew
>
> -----Ursprüngliche Nachricht-----
> Von: Andrew Stitcher [mailto:astitcher@redhat.com]
> Gesendet: Freitag, 11. September 2015 18:12
> An: proton@qpid.apache.org
> Betreff: Re: AW: SASL negotiation w/ EXTERNAL
>
> On Wed, 2015-09-09 at 17:03 +0000, Clemens Vasters wrote:
> > ...
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
> > w.o
> > asis
> > -open.org%2fcommittees%2fdocument.php%3fdocument_id%3d50506%26&dat
> > a=01%7c01%7cclemensv%40microsoft.com%7c06d400131a5945f544bb08d2bac3
> > ca0
> > 2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AGNP6Xe0lSYS1oUOrXEa
> > o55
> > 1nsqmeP98BZpQpf0ggq8%3d
> > wg_abbrev=amqp
>
> I looked at this and I agree it does seem quite powerful.
>
> IUC you need an authenticated AMQP connection of some sort (ANON
> would
> work) to send the claims though.
>
> So I still don't understand why the server would be offering EXTERNAL
> seeing as it already knows that the client certificate isn't good
> enough to authenticate the connection.
>
> [Not a objection to adding the new messenger API, it just seems like
> the service bus behaviour is wrong to me]
>
> Andrew
>
AW: AW: SASL negotiation w/ EXTERNAL
Posted by Clemens Vasters <cl...@microsoft.com>.
Sorry about the late reply; I'm traveling.
The current behavior of Service Bus of offering up EXTERNAL in spite of not having gotten and verified a client credential at the TLS level not correct, and we've identified that as a bug on our side in the process of digging through this.
Would the acceptable fix have to plumb the new API through all bindings?
-----Ursprüngliche Nachricht-----
Von: Andrew Stitcher [mailto:astitcher@redhat.com]
Gesendet: Freitag, 11. September 2015 18:12
An: proton@qpid.apache.org
Betreff: Re: AW: SASL negotiation w/ EXTERNAL
On Wed, 2015-09-09 at 17:03 +0000, Clemens Vasters wrote:
> ...
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.o
> asis-open.org%2fcommittees%2fdocument.php%3fdocument_id%3d50506%26&dat
> a=01%7c01%7cclemensv%40microsoft.com%7c06d400131a5945f544bb08d2bac3ca0
> 2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AGNP6Xe0lSYS1oUOrXEao55
> 1nsqmeP98BZpQpf0ggq8%3d
> wg_abbrev=amqp
I looked at this and I agree it does seem quite powerful.
IUC you need an authenticated AMQP connection of some sort (ANON would
work) to send the claims though.
So I still don't understand why the server would be offering EXTERNAL seeing as it already knows that the client certificate isn't good enough to authenticate the connection.
[Not a objection to adding the new messenger API, it just seems like the service bus behaviour is wrong to me]
Andrew
Re: AW: SASL negotiation w/ EXTERNAL
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2015-09-09 at 17:03 +0000, Clemens Vasters wrote:
> ...
> https://www.oasis-open.org/committees/document.php?document_id=50506&
> wg_abbrev=amqp
I looked at this and I agree it does seem quite powerful.
IUC you need an authenticated AMQP connection of some sort (ANON would
work) to send the claims though.
So I still don't understand why the server would be offering EXTERNAL
seeing as it already knows that the client certificate isn't good
enough to authenticate the connection.
[Not a objection to adding the new messenger API, it just seems like
the service bus behaviour is wrong to me]
Andrew
AW: SASL negotiation w/ EXTERNAL
Posted by Clemens Vasters <cl...@microsoft.com>.
Hi Andrew,
we're implementing this OASIS WG CBS draft written by Dave Ingham a while back. We'll have to give that love in the TC to drive it to completion as it has been sitting around, but we have it in production in Service Bus and Event Hubs. This allows setting per-node security tokens, and also replacing expiring tokens without getting in the way of the message flow. It also allows a client to establish an authenticated or anonymous connection with the broker and subsequently only allowing links when a token has been set for the link target, i.e. you can have 10 different tokens for 10 different targets multiplexed over the same connection. It's quite powerful.
https://www.oasis-open.org/committees/document.php?document_id=50506&wg_abbrev=amqp
I could make the two functions; where do I learn the house rules with regards to docs/tests/samples?
The JIRA issue is https://issues.apache.org/jira/browse/PROTON-988
Best Regards
Clemens
-----Ursprüngliche Nachricht-----
Von: Andrew Stitcher [mailto:astitcher@redhat.com]
Gesendet: Mittwoch, 9. September 2015 18:41
An: proton@qpid.apache.org
Betreff: Re: SASL negotiation w/ EXTERNAL
On Wed, 2015-09-09 at 15:57 +0000, Clemens Vasters wrote:
> 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,
This is a new thing to me - do you have a pointer to documentationa about the "claims-based" (access control?) model.
> 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.
As I said I'm not against this - I significantly prefer a new API rather than flags for the reasons I stated earlier.
pn_messenger_set_allowed_sasl_mechs() seems like a reasonable (if
wordy) name (together with an accessor pn_messenger_get_...).
>
> 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.
Can you point me at the JIRA for this bug?
Thanks
Andrew
Re: SASL negotiation w/ EXTERNAL
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2015-09-09 at 15:57 +0000, Clemens Vasters wrote:
> 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,
This is a new thing to me - do you have a pointer to documentationa
about the "claims-based" (access control?) model.
> 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.
As I said I'm not against this - I significantly prefer a new API
rather than flags for the reasons I stated earlier.
pn_messenger_set_allowed_sasl_mechs() seems like a reasonable (if
wordy) name (together with an accessor pn_messenger_get_...).
>
> 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.
Can you point me at the JIRA for this bug?
Thanks
Andrew
RE: SASL negotiation w/ EXTERNAL
Posted by Clemens Vasters <cl...@microsoft.com>.
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
Clemens
-----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 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.
Andrew
Re: SASL negotiation w/ EXTERNAL
Posted by Andrew Stitcher <as...@redhat.com>.
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.
Andrew