Re: unread variables in sunrpc kerberos code

Re: unread variables in sunrpc kerberos code

[J. Bruce Fields]

Adding the linux-nfs list on the cc in case somebody else has looked at
this more recently than me....

On Wed, Oct 09, 2013 at 12:20:29AM +0200, Andi Kleen wrote:
> > I think it's probably harmless, though it wouldn't be a bad idea to
> > review it if somebody had the time.
>
> Can you explain why it is harmless? Is the sequence number
> checked elsewhere? If yes, where?

I really don't remember.

OK, I give in, I'll go look:

RFC 1964 section 1.2.1.2 says

	The sequence number provides a basis for detection of replayed
	tokens.  Replay detection *can* be performed using state
	information retained on received sequence numbers...

(emphasis mine), and

	Provision of per-message replay and out-of-sequence detection
	services is optional for implementation of the Kerberos V5
	GSS-API mechanism.

For some reason RFC 4121, which appears to be the one describing the v2
tokens, doesn't have similar text that I can find.  I can't tell what
they think you're supposed to do with sequence numbers, if anything.

RPC's (hence gss tokens) can be processed out of order, so it's a little
unclear how the sequence numbers would be checked.  You'd have to choose
a window of sequence numbers to track, I guess, and just reject anything
older.  Absence any guidance about how to do this in the RFC's this
sounds like a potential source of interoperability problems.

RPCSEC_GSS also has its own sequence number that's included in all the
data we encrypt or checksum, so should provide sufficient replay
protection on its own.  And the RPCSEC_GSS RPC's do tell you how to
determine the window and handle old tokens.

So I may be missing something--more review always welcomed--but I think
it's all OK.

Unless someone else has more to add I'll cook up a patch that attempts
to make the situation clearer to future unfortunate readers of this
code.

--b.

Re: unread variables in sunrpc kerberos code

[Andy Adamson]

RPCSEC_GSS requires that the GSS-API level sequencing is turned off -
e.g. the sequence_req_flag is set to false.

rfc2203:

  When GSS_Init_sec_context() is called, the parameters
  replay_det_req_flag and sequence_req_flag must be turned off. The
  reasons for this are:

  *    ONC RPC can be used over unreliable transports and provides no
        layer to reliably re-assemble messages. Thus it is possible for
        gaps in message sequencing to occur, as well as out of order
        messages.

   *    RPC servers can be multi-threaded, and thus the order in which
        GSS-API messages are signed or wrapped can be different from the
        order in which the messages are verified or unwrapped, even if
        the requests are sent on reliable transports.

   *    To maximize convenience of implementation, the order in which an
        ONC RPC entity will verify the header and verify/unwrap the body
        of an RPC call or reply is left unspecified.

   The RPCSEC_GSS protocol provides for protection from replay attack,
   yet tolerates out-of-order delivery or processing of messages and
   tolerates dropped requests.


So the RPCSEC_GSS layer does the sequencing, not the GSS layer.

-->Andy

On Wed, Oct 9, 2013 at 12:28 PM, J. Bruce Fields <bfields@redhat.com> wrote:
> Adding the linux-nfs list on the cc in case somebody else has looked at
> this more recently than me....
>
> On Wed, Oct 09, 2013 at 12:20:29AM +0200, Andi Kleen wrote:
>> > I think it's probably harmless, though it wouldn't be a bad idea to
>> > review it if somebody had the time.
>>
>> Can you explain why it is harmless? Is the sequence number
>> checked elsewhere? If yes, where?
>
> I really don't remember.
>
> OK, I give in, I'll go look:
>
> RFC 1964 section 1.2.1.2 says
>
>         The sequence number provides a basis for detection of replayed
>         tokens.  Replay detection *can* be performed using state
>         information retained on received sequence numbers...
>
> (emphasis mine), and
>
>         Provision of per-message replay and out-of-sequence detection
>         services is optional for implementation of the Kerberos V5
>         GSS-API mechanism.
>
> For some reason RFC 4121, which appears to be the one describing the v2
> tokens, doesn't have similar text that I can find.  I can't tell what
> they think you're supposed to do with sequence numbers, if anything.
>
> RPC's (hence gss tokens) can be processed out of order, so it's a little
> unclear how the sequence numbers would be checked.  You'd have to choose
> a window of sequence numbers to track, I guess, and just reject anything
> older.  Absence any guidance about how to do this in the RFC's this
> sounds like a potential source of interoperability problems.
>
> RPCSEC_GSS also has its own sequence number that's included in all the
> data we encrypt or checksum, so should provide sufficient replay
> protection on its own.  And the RPCSEC_GSS RPC's do tell you how to
> determine the window and handle old tokens.
>
> So I may be missing something--more review always welcomed--but I think
> it's all OK.
>
> Unless someone else has more to add I'll cook up a patch that attempts
> to make the situation clearer to future unfortunate readers of this
> code.
>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unread variables in sunrpc kerberos code

[J. Bruce Fields]

On Wed, Oct 09, 2013 at 02:33:22PM -0400, Andy Adamson wrote:
> RPCSEC_GSS requires that the GSS-API level sequencing is turned off -
> e.g. the sequence_req_flag is set to false.
> 
> rfc2203:
> 
>   When GSS_Init_sec_context() is called, the parameters
>   replay_det_req_flag and sequence_req_flag must be turned off. The
>   reasons for this are:
> 
>   *    ONC RPC can be used over unreliable transports and provides no
>         layer to reliably re-assemble messages. Thus it is possible for
>         gaps in message sequencing to occur, as well as out of order
>         messages.
> 
>    *    RPC servers can be multi-threaded, and thus the order in which
>         GSS-API messages are signed or wrapped can be different from the
>         order in which the messages are verified or unwrapped, even if
>         the requests are sent on reliable transports.
> 
>    *    To maximize convenience of implementation, the order in which an
>         ONC RPC entity will verify the header and verify/unwrap the body
>         of an RPC call or reply is left unspecified.
> 
>    The RPCSEC_GSS protocol provides for protection from replay attack,
>    yet tolerates out-of-order delivery or processing of messages and
>    tolerates dropped requests.
> 
> 
> So the RPCSEC_GSS layer does the sequencing, not the GSS layer.

Thanks Andy, that RFC text is a good explanation;  I'll add a comment
referencing that.

--b.

Re: unread variables in sunrpc kerberos code

[Andi Kleen]

Thanks for following up. Looks good.
-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.