NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Theodore Ts'o <tytso@mit.edu>
Steve Nahm <sxn@sun.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:oncrpc-wg@sunroof.eng.sun.com
To Subscribe: oncrpc-wg-request@sunroof.eng.sun.com
Archive: ftp://playground.sun.com/pub/oncrpc
Description of Working Group:
The Open Network Computing Remote Procedure Call Working Group was originally formed to update the RFCs that describe ONC RPC to reflect the current state of the deployed and accepted technology, and submit them for Internet standardization. RFCs have been submitted for the three core ONC technologies: RPC (RFC1831), RPC Binding (RFC 1833) and XDR (RFC1832).
During this work, IESG identified the area of security as requiring improvement prior to standardizing the core RPC technologies (RPC and RPC Binding). Therefore, the Working Group shall develop and define a security mechanism for ONC RPC which shall, at the minimum, allow for strong authentication of client and server principals. The core RPC technologies will be unblocked from the standards track once such a mechanism is approved as a Proposed Standard, provided that its design does not require changes to the core RPC technologies.
The basis for the work will be the RPCSEC_GSS Protocol Specification, draft-ietf-oncrpc-rpcsec_gss.00.txt.
The document editor will be Michael Eisler.
Background:
ONC RPC is a Remote Procedure Call technology that originated in Sun Microsystems in the early 1980s. ONC RPC was modeled on Xerox's Courier RPC protocols. It has been widely deployed on platforms from most major workstation vendors. It has been implemented on MS-DOS, Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and practically all flavors of UNIX, among others. Sun Microsystems has delegated change control for the ONC RPC protocols for the purposes of making an Internet Standard to the IETF (see RFC 1790).
Goals and Milestones:
Done |
|
Post RPC: Remote Procedure Call Protocol Specification Version 2 (update of RFC 1057) as an Internet-Draft. |
Done |
|
Post XDR: External Data Representation Standard (an update of RFC 1014) as an Internet-Draft. |
Done |
|
Submit RPC document to IESG for consideration as a Proposed Standard. |
Done |
|
Submit XDR document to IESG for consideration as a Proposed Standard. |
Feb 97 |
|
Submit strong security mechanism for ONC RPC to IESG for consideration as a Proposed Standard. |
Mar 97 |
|
Submit core RPC documents to IESG for consideration as Draft Standards. |
Mar 97 |
|
Conclude working group, leaving mailing list in place for pursuit of the subsequent standards stages. |
Apr 97 |
|
submit XDR to IESG for consideration as Internet Standards. |
Aug 97 |
|
Submit Strong security mechanism to IESG for consideration as a Draft Standard. |
Internet-Drafts:
· Authentication Mechanisms for ONC RPC
· RPC: Remote Procedure Call Protocol Specification Version 2
· BGP Security Analysis
Request For Comments:
RFC |
Status |
Title |
RFC1832 |
PS |
XDR: External Data Representation Standard |
RFC1831 |
PS |
RPC: Remote Procedure Call Protocol Specification Version 2 |
RFC1833 |
PS |
Binding Protocols for ONC RPC Version 2 |
RFC2203 |
PS |
RPCSEC_GSS Protocol Specification |
Minutes of the ONC Remote Procedure Call (oncrpc) Working group
Reported by Ram Marti and Steve Nahm
The working group met in one session on Tuesday. Co-chairs Steve Nahm (Sun Microsystems) and Ted Tso (MIT) were present. Three sets of slides and one paper were prepared for this meeting and will be submitted with these minutes.
I. Status of Working Group Documents
Steve Nahm presented the status of the working group's drafts and RFCs.
There is one RFC at Draft Standard status:
RFC1832: XDR: External Data Presentation Standard
There are three RFCs at Proposed Standard:
RFC1831: RPC: Remote Procedure Call Protocol Specification Version 2
RFC1833: Binding Protocols for ONC RPC Version 2
RFC2203: RPCSEC_GSS Protocol Specification
RFC1831 (and thus RFC1833 and RFC2203) is being held at Proposed Standard until arrangements have been completed to transfer responsibility for the assignment of RPC numbers and Authentication numbers to the Internet Assigned Number Authority (IANA).
One working group draft is currently active: draft-ietf-oncrpc-auth-04.txt (Authentication Mechanisms)
This document will be submitted shortly for consideration as an Informational RFC.
II. RPC Number Assignments
Steve sought to resolve a few issues that were of concern to him in writing the instructions for IANA to use in assigning numbers. Issues discussed in his presentation were:
· Should there be a control on assigning large blocks of RPC numbers?
Ted Tso concurred that assigning a large block of RPC program numbers should be controlled. There was a general consensus that assignment of large block of numbers should be controlled by IANA. One suggestion was to provide IANA with a "expert" with whom they can consult if unusual requests are received (such as for a large block of numbers).
Should additional constraints be placed on the assignment of new Authentication flavors?
Steve asked whether we should ask that the assignment of new Authentication flavor numbers be contingent on publication of a specification for the proposed new flavor; or whether we should explicitly encourage developers of new flavors to look first at using RPCSEC_GSS instead.
While publication of specification is always desirable, several people felt that this should not be made a requirement. Regarding RPCSEC_GSS, the group did agree that proposers of new flavors should be informed about RPCSEC_GSS as an architecture that can accommodate new security mechanisms, but that we cannot require that RPCSEC_GSS be used. An example was given where RPCSEC_GSS may not be the best solution for some users of RPC: RPCSEC_GSS requires that a security context be established prior to use, which takes additional RPC traffic. For applications that have a critical performance requirement, this overhead may be excessive. These users may want something simpler, such as an improved AUTH_DH.
· Should IANA assign Authentication flavors starting at 7?
The last flavor that has been assigned by Sun is RPCSEC_GSS, which is assigned flavor number "6". IANA could start assigning new flavors from this point, or could start from 400,000 as is being proposed for RPC numbers (see the slides for Steve's talk). The consensus was to start at 7.
A request was made that the legacy assignments for both RPC and Authentication numbers be published as part of the handover to IANA. Steve agreed that this should be done.
III. XDR Improvements
Bill Janssen (Xerox PARC) presented several ideas for improving XDR. Please refer to the slides for his talk included with the minutes. These suggestion were, under functional improvements, an improved string data type and "aliased reference types". Under performance improvements he discussed support for "either-endian" encoding and more efficient encoding (packing) of data.
Bill's proposal for a new string data type is intended to address the lack of international character support in XDR. Such support has been specified as a "Best Current Practice" by RFC2277, "IETF Policy on Character Sets and Languages". Bill's proposal received much discussion, particularly regarding his proposal to include a specifier for both "character set" and "language" in his proposed new "xstring" data type.
Steve asked whether RFC1832 could be stopped from proceeding to Internet Standard due to the requirements of RFC2277. No one present knew this to be the case. Bill's proposal is to define xstring, or whatever the new datatype would be called, as a supplement to the current XDR specification, allowing RFC1832 to proceed separately.
No strong consensus was reached regarding Bill's proposal, but he was asked to continue working on the idea and submit a more detailed proposal for the working group to consider.
Bill and others requested that RFC1832 should be updated to clarify the use of "ASCII" in the current "string" type. Also, mention was made that some implementations of XDR do not handle strings as a vector of counted bytes, as defined in the specification, but rather as a string of characters terminated by a NULL. This should also be clarified. Steve agreed to submit a revision to RFC1832 which would address both of these points.
Someone asked whether Sun would consider submitting "UTF-Java", which represents NULL in a string-safe way, for standardization as a character set. No one from Sun at the meeting knew what the company's intentions were for this character set.
Bill next discussed Aliased Reference Types. Glenn stated that his proposal would introduce some state into XDR, which currently is stateless. However, the layer that uses XDR can decide how or whether to introduce state. RPC, for example, can constrain aliased reference types to the current call (limiting the value of aliased types). Or the RPC application can maintain the state itself to determine across what scope the aliased types would be valid.
A suggestion was made for Bill to develop this idea as an experimental protocol, since there were several significant issues that were not fully understood. Bill agreed to do this.
Bill next argued for supporting either-endian encoding of data in XDR. He is motivated by the sheer numbers of little-endian systems in the world, and the great benefit that this small change would accrue to users of these systems.
Bill's proposal was to tie "endianess" to an XDR stream, not allowing changes in midstream. Similar to the previous proposal, the RPC application layer could decide on the endianess, leaving RPC itself unchanged.
Comments were made that the performance issue is really not significant, particularly when marshalling requires copying of data (see Glenn Davis's paper included with these minutes). Bill stated that byte-swapping becomes very significant when transferring large arrays of floating point numbers. In general, however, there was not a great deal of support for this idea, though Bill was welcome to continue developing it for future consideration.
Bill then discussed support for "packing" data, which would eliminate the space currently wasted by XDR's encoding of datatypes smaller than 32-bits, which includes padding. Bill also suggested a "bounded" type where the user could specify the range of possible values that an integer type can support, allowing the complier to decide what is the most efficient representation.
Brent Callaghan then took the floor to discuss his ideas for XDR improvements. Please refer to his slides for more details.
His first proposal was to support data types that explicitly stated their size: int32, int64. "hyper", in particular, is a name that is not recognized as a data type outside of XDR. There was general agreement that this proposal was beneficial.
Brent next suggested that a "list" keyword be added to RPCL to simplify the declaration of the common linked-list structure. The group did not have a strong consensus to do this or that it is needed, but agreed that it might improve XDR's usability for linked-lists.
Brent then made his own suggestions for packing data and for smaller data types (such as "int16" or "short" for two bytes and "int8" or "byte" for one byte). As with Bill's proposal, Brent's suggestion needs to be fleshed out more for the working group to be able to fully consider the proposal.
Brent next suggested reducing RPC Language's verbosity by allowing for anonymous "structs or by eliminating structs and unions altogether. One motivation for this is making RPC Language more compatible with Java, where structs become a multitude of small classes. One comment was that eliminating the "name" of a struct can be troublesome because implementors often end up wanting to refer to a specific struct. Again, this proposal needs more development. Brent agreed to prepare a more detailed proposal for this and other suggestions he made in his presentation.
XDR Extension Suggestions
Possible XDR Extensions
ONCRPC - Agenda
Roster Not Submitted