Ethereal-dev: Re: [Ethereal-dev] Changing dissect_rpc_data which is called from dissect_nfsdat
On Tue, May 20, 2003 at 12:10:00AM -0700, Richard Sharpe wrote:
> We know at the NFSv4 layer, it seems, that there is an OID in the opaque
> data ... it seems that the RPC layer doesn't necessarily know that info.
OK, so this is for the SECINFO reply, not for anything else in NFSv4 or
for anything else in any other ONC RPC protocol.
> This data is in the secinfo reply. The nfs layer knows that it is dealing
> with RPCSEC_GSS data ... The following routine is only called for handling
> the secinfo data in a reply to a request that specifies secinfo.
>
> static int
> dissect_nfs_rpcsec_gss_info(tvbuff_t *tvb, int offset, proto_tree *tree)
> {
> /*
> * What we have in the first portion is an OID, so dissect it the
> * correct way
> */
> offset = dissect_nfsdata(tvb, offset, tree, hf_nfs_sec_oid4,
> NULL);
> offset = dissect_rpc_uint32(tvb, tree, hf_nfs_qop4, offset);
> offset = dissect_rpc_uint32(tvb, tree,
> hf_nfs_secinfo_rpcsec_gss_info_service, offset);
>
> return offset;
> }
>
> I don't want to call the GSSAPI dissector just to dissect an OID, and in
> any case, it seems that it is an ASN1 OID, not a GSSAPI token at this
> stage, which might mean that the people who sent me the capture have a
> broken implementation ...
If it's *not* an ASN.1 OID, it's a broken implementation, at least as I
read RFC 3010:
2.1. Basic Data Types
...
sec_oid4 typedef opaque sec_oid4<>;
Security Object Identifier
The sec_oid4 data type is not really opaque.
Instead contains an ASN.1 OBJECT IDENTIFIER as used
by GSS-API in the mech_type argument to
GSS_Init_sec_context. See [RFC2078] for details.
...
14.2.31. Operation 33: SECINFO - Obtain Available Security
SYNOPSIS
(cfh), name -> { secinfo }
ARGUMENT
struct SECINFO4args {
/* CURRENT_FH: */
component4 name;
};
RESULT
enum rpc_gss_svc_t {
RPC_GSS_SVC_NONE = 1,
RPC_GSS_SVC_INTEGRITY = 2,
RPC_GSS_SVC_PRIVACY = 3
};
struct rpcsec_gss_info {
sec_oid4 oid;
qop4 qop;
rpc_gss_svc_t service;
};
struct secinfo4 {
uint32_t flavor;
opaque flavor_info<>; /* null for AUTH_SYS, AUTH_NONE;
contains rpcsec_gss_info for
RPCSEC_GSS. */
};
typedef secinfo4 SECINFO4resok<>;
union SECINFO4res switch (nfsstat4 status) {
case NFS4_OK:
SECINFO4resok resok4;
default:
void;
};
DESCRIPTION
The SECINFO operation is used by the client to obtain a list of
valid RPC authentication flavors for a specific file handle, file
name pair. The result will contain an array which represents the
security mechanisms available. The array entries are represented
by the secinfo4 structure. The field 'flavor' will contain a
value of AUTH_NONE, AUTH_SYS (as defined in [RFC1831]), or
RPCSEC_GSS (as defined in [RFC2203]).
For the flavors, AUTH_NONE, and AUTH_SYS no additional security
information is returned. For a return value of RPCSEC_GSS, a
security triple is returned that contains the mechanism object id
(as defined in [RFC2078]), the quality of protection (as defined
in [RFC2078]) and the service type (as defined in [RFC2203]). It
is possible for SECINFO to return multiple entries with flavor
equal to RPCSEC_GSS with different security triple values.
On success, the current filehandle retains its value.
Given that, I'd say that this is an issue of truly-opaque data (such as
the data in read replies and write requests) vs. "opaque" data whose
format is defined by something outside RPC/XDR. There are several ways
in which the latter could be handled, such as:
1) have "dissect_rpc_data()" take an extra argument, and modify
all the calls (presumably a null function pointer means "it
truly is opaque"), and have "dissect_nfsdata()" pass on its
extra argument;
2) add "dissect_rpc_data_ex()", have "dissect_nfsdata()" call it
instead of "dissect_rpc_data()", and pass on an extra
argument;
3) have "dissect_rpc_opaque_data()" take an extra argument,
modify the few calls there are to *it*, export it from
"packet-rpc.c", have "dissect_nfs_rpcsec_gss_info()" call
"dissect_rpc_opaque_data()", and don't change
"dissect_nfsdata()" (except perhaps to eliminate it in favor
of calling "dissect_rpc_data()" directly!) or
"dissect_rpc_data()" at all.
My preference is for 3) - modifying "dissect_nfsdata()", which is called
in many places, most of which *aren't* ASN.1 OIDs, seems to me to be the
wrong solution, and tweaking "dissect_rpc_opaque_data()" requires the
fewest calls to be changed *AND* might even allow us to get rid of the
"string_data" Boolean argument to "dissect_rpc_opaque_data()" in favor
of passing it a "show this as a character string" routine.
