SASL GSSAPI and MIN-MAX-FRAME-SIZE

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SASL GSSAPI and MIN-MAX-FRAME-SIZE

Gary Tully
Hi,
I have been working through adding SASL GSSAPI (Kerberos) support to the
qpid-jms-client[1] and have hit a limit in proton-j

The initial response in the SASL_Init frame can be > 512 which breaks the
max frame size limitation as frame size negotiation has not completed yet.
Proton-j will allow the frame to be written but the parse at the other end
identifies the size exceeding the limit and errors out.

I see in the AMQP Claims Based Security draft there is some work to
describe how to SASL within that limitation in the context of a new
mechanism.

Is it reasonable to relax the check via config to allow the existing gssapi
mechanism to work.

Of the top of your head, what does proton-c do, maybe it never sends an
initial response in the sasl_init?

thanks in advance for any read of this :-)

gary.

[1] https://issues.apache.org/jira/browse/QPIDJMS-303
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SASL GSSAPI and MIN-MAX-FRAME-SIZE

Robbie Gemmell
Administrator
On 26 July 2017 at 14:09, Rob Godfrey <[hidden email]> wrote:

> On 26 July 2017 at 14:43, Robbie Gemmell <[hidden email]> wrote:
>
>> That essentially summarises some discussion I had with others on this
>> elsewhere late yesterday and was planning to see what you and others
>> thought about it after having a look at the impls.
>>
>> I agree that making a custom mechanism for fragmenting an existing
>> mechanisms content is ugly and probably of little value in the end
>> since you would still need to handle the whole as you say. If the
>> regular mechanism name was offered and it needs >512 byte in a given
>> situation then it obviously wouldnt work if you enforce that limit..so
>> either you couldnt expect it to work anyway, in which case why offer
>> it, or presumably wouldnt enforce the limit. If servers dont offer
>> such mechanism or clients dont select them, which many wont in this
>> case, there isn't an issue for them.
>>
>> To allow proceeding despite the size, we would need to add a toggle to
>> proton-j to control what it will allow to be received for sasl frames,
>> or adjust the default size it will allow, or both. The simplest thing
>> toggle wise would look to be making the existing transport 'remote max
>> frame size' overridable until set by the Open frame arriving and use
>> it to govern this behaviour.
>>
>
> That (configurable initial maximum) sounds sensible to me.  Ultimately
> outside of the (in-discussion) CBS mechanism neither side really has much
> influence over the size of the data being exchanged.  Out of interest, on
> the sending size does proton already just send large SASL frames if you
> supply it with > 512 bytes of data, or does it error?
>
> -- Rob
>

It does just send them, yes.

>
>>
>> Robbie
>>
>> On 26 July 2017 at 09:34, Rob Godfrey <[hidden email]> wrote:
>> > *sigh* I always thought 512 was a bit on the low side for this limit :-(
>> >
>> > For background the original intent of setting MIN-MAX-FRAME-SIZE at 512
>> > bytes was to allow AMQP to be used on devices with very limited
>> resources.
>> > Logic(?) then dictated that all frames exchanged prior to a new max frame
>> > size being agreed need to fit within the known minimum frame size limit.
>> > In retrospect for SASL this was a mistake, as normally you don't really
>> > have any choice ab out how big your sasl frames are going to be (the size
>> > will be determined by the requirements of the mechanism).  If (say) we
>> > allowed proton to be more relaxed in the frame sizes it allows (we'd
>> still
>> > want some limit to prevent DoS style attacks) then the worst that happens
>> > (I think) is that SASL mechanisms that require larger frames will not
>> work
>> > against implementations which enforce the 512 byte limit... but then such
>> > implementations can't realistically be supporting mechanisms which
>> require
>> > larger exchanges (such as GSSAPI/Kerberos).  I don't really see the value
>> > in inventing a new SASL mechanism for this (allowing fragmentation of the
>> > responses) as in reality this wouldn't help systems with limited
>> resources
>> > implement the mechanism (they'll still need to assemble the whole
>> response
>> > at some point I imagine).  Techniacally this will be spec violating, but
>> > OTOH without violating the spec you can't implement the mechanism, so if
>> > you offer the mechanism then you are implicitly saying "I'm not going to
>> > enforce this rule".
>> >
>> > -- Rob
>> >
>> > On 25 July 2017 at 18:02, Gary Tully <[hidden email]> wrote:
>> >
>> >> Hi,
>> >> I have been working through adding SASL GSSAPI (Kerberos) support to the
>> >> qpid-jms-client[1] and have hit a limit in proton-j
>> >>
>> >> The initial response in the SASL_Init frame can be > 512 which breaks
>> the
>> >> max frame size limitation as frame size negotiation has not completed
>> yet.
>> >> Proton-j will allow the frame to be written but the parse at the other
>> end
>> >> identifies the size exceeding the limit and errors out.
>> >>
>> >> I see in the AMQP Claims Based Security draft there is some work to
>> >> describe how to SASL within that limitation in the context of a new
>> >> mechanism.
>> >>
>> >> Is it reasonable to relax the check via config to allow the existing
>> gssapi
>> >> mechanism to work.
>> >>
>> >> Of the top of your head, what does proton-c do, maybe it never sends an
>> >> initial response in the sasl_init?
>> >>
>> >> thanks in advance for any read of this :-)
>> >>
>> >> gary.
>> >>
>> >> [1] https://issues.apache.org/jira/browse/QPIDJMS-303
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...