Re: 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

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

Robbie Gemmell
Administrator
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.

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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

rgodfrey
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


>
> 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]
>
>
Loading...