[
https://issues.apache.org/jira/browse/PROTON-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141394#comment-16141394
]
Robbie Gemmell commented on PROTON-1555:
----------------------------------------
I'm not sure this is correct. The router behaviour actually seems consistent
with the SASL RFC definition of EXTERNAL:
{quote}
The client is expected to send data first in the authentication exchange.
Where the client does not provide an initial response data in its request to
initiate the authentication exchange, the server is to respond to the request
with an empty initial challenge and then the client is to provide its initial
response.
{quote}
https://tools.ietf.org/html/rfc4422#page-29
I think it is the client that needs changed, if I'm interpreting the report
correctly that it is rhea which doesn't send an initial response and then falls
over when challenged for one by the router.
> SASL External and missing initial-response
> ------------------------------------------
>
> Key: PROTON-1555
> URL: https://issues.apache.org/jira/browse/PROTON-1555
> Project: Qpid Proton
> Issue Type: Bug
> Reporter: Ulf Lilleengen
> Assignee: Gordon Sim
> Attachments: sasl-external-reproducer.tar.gz
>
>
> We're facing an issue where the router or proton seems to require the
> initial-response in the sasl-init frame to be set.
> I've attached a reproducer that reproduces the error. It contains a router
> config which you can start the router with. It also contains a qdmanage.sh
> script that shows the exchange when using qdmanage. The router log trace
> looks like this (initial-response is an empty string)
> 2017-08-25 10:17:21.500716 +0200 SERVER (info) Accepted connection to
> 0.0.0.0:55671 from 127.0.0.1:53196
> [0x7fd630042480]: <- SASL
> [0x7fd630042480]: -> SASL
> [0x7fd630042480]:0 -> @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x7fd630042480]:0 <- @sasl-init(65) [mechanism=:EXTERNAL,
> initial-response=b""]
> [0x7fd630042480]:0 -> @sasl-outcome(68) [code=0]
> The error occurs when connecting with a client that doesnt set the
> initial-response at all. The router log:
> 2017-08-25 10:16:59.851029 +0200 SERVER (info) Accepted connection to
> 0.0.0.0:55671 from 127.0.0.1:53192
> [0x7fd630014740]: <- SASL
> [0x7fd630014740]: -> SASL
> [0x7fd630014740]:0 -> @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x7fd630014740]:0 <- @sasl-init(65) [mechanism=:EXTERNAL]
> [0x7fd630014740]:0 -> @sasl-challenge(66) [challenge=b""]
> The rhea client will crash with the following error:
> events.js:160
> throw er; // Unhandled 'error' event
> ^
> TypeError: this.mechanism.step is not a function
>
> at SaslClient.on_sasl_challenge
> (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/sasl.js:214:35)
>
> at c.dispatch
> (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/types.js:902:33)
>
> at Transport.read
> (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/transport.js:95:36)
>
> at SaslClient.read
> (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/sasl.js:245:31)
>
> at Connection.input
> (/home/lulf/git/enmasse/enmasse/reproducer/node_modules/rhea/lib/connection.js:420:35)
>
> at emitOne (events.js:96:13)
> at TLSSocket.emit (events.js:188:7)
> at readableAddChunk (_stream_readable.js:176:18)
>
> at TLSSocket.Readable.push (_stream_readable.js:134:10)
>
> at TLSWrap.onread (net.js:547:20)
> Rob tells me that the router response is not what you'd expect and that it
> should handle a sasl init without an initial-response.
> If we ExternalClient.prototype.start in rhea sasl.js to return an empty
> string instead of null, the exchange goes well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
