rfc3224.txt

RFC 的详细文档！


RFC 3224             Vendor Extensions for Service          January 2002


5.1. Vendor Opaque Extension Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Extension ID = 0x0003     |       Next Extension Offset   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Offset, contd.|               Enterprise Number               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ent. #, contd.|                Extension Data                 /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Enterprise Number is included in the Extension as a 4 byte
   unsigned integer value.  The Extension Data following is guaranteed
   to have an unambiguous interpretation determined by the vendor.

5.2 Example: Acme Extension for UA Authentication

   The Acme Corporation, whose Enterprise Number is 9999, can define an
   extension to SLP.  In this example, Acme creates one such extension
   to create an application level access control to service information.
   This would allow replies to be sent only to clients who could
   authenticate themselves.

   The engineers at Acme give the Extension Data the following form:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ACME Ext ID = 1|       Client ID  Length       |   Client ID ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Authenticator                        ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ACME Ext ID:  The ACME engineers decided to define the first byte of
   their extension data as an extension ID field.  In the future, ACME
   may decide to define more than this extension.  Since there is 8 bits
   in the ID field, ACME can define up to 256 different extensions.  If
   ACME were to omit this field and begin directly with their 'Extension
   for UA Authentication', they would only be able to define one ACME
   specific SLP extension.  For the 'Extension for UA Authentication,'
   the ACME Extension ID is set to 1.  This ID has to be managed within
   ACME, to make sure that each new extension they invent has a unique
   ID assigned to it.





Guttman                     Standards Track                     [Page 6]

RFC 3224             Vendor Extensions for Service          January 2002


   Client ID Length:  This declares how many bytes of Client ID data
   follow.

   Client ID: The Acme application user ID.

   Timestamp: # of seconds since January 1, 2000, 0:00 GMT.

   Authenticator: a 16 byte MD5 digest [6] calculated on the following
   data fields, concatenated together

      -  UA request bytes, including the header, but not any extensions.
      -  UA SECRET PASS PHRASE
      -  Acme UA Authentication Extension - Client ID
      -  Acme UA Authentication Extension - Timestamp

   The SA or DA which receives this extension and supports this
   extension will check if it (1) recognizes the Client ID, (2) has an
   associated SECRET PASS PHRASE for it, (3) whether upon calculating an
   MD5 digest over the same data as listed above it arrives at the same
   Authenticator value as included in the extension.  If all 3 of these
   steps succeed, the UA has been authenticated.

   Note this example is for explanatory purposes only.  It would not
   work well in practice.  It requires a shared secret be configured in
   SAs and DAs, for every UA.  Furthermore, the UA secret pass phrase
   would be susceptible to a dictionary attack.

6.0 Extensions Requiring IETF Action

   Modification or extension of any feature of SLPv2 whatsoever, aside
   from those listed in Sections 3-5 of this document, requires a
   standards action as defined in [1].

   Terminology and procedures for IETF Actions related to registration
   of IDs with IANA are defined in [5].  Existing SLPv2 extensions
   assignments are registered with IANA [3].

7.0 IANA Considerations

   This document clarifies procedures described in other documents [1]
   [4].  The Vendor Opaque Extension ID has already been registered [3].
   No additional IANA action is required for publication of this
   document.








Guttman                     Standards Track                     [Page 7]

RFC 3224             Vendor Extensions for Service          January 2002


8.0 Security Considerations

   Vendor extensions may introduce additional security considerations
   into SLP.

   This memo describes mechanisms which are standardized elsewhere [1]
   [4].  The only protocol mechanism described in this document (see
   Section 5 above) is no less secure than 'private use' extensions
   defined in SLPv2 [1].

   The example in Section 5.2 above shows how Vendor Opaque Extensions
   can be used to include an access control mechanism to SLP so that SAs
   can enforce an access control policy using an authentication
   mechanism.  This is merely an example and protocol details were
   intentionally not provided.  A vendor could, however, create a
   mechanism similar to this one and provide additional security
   services to SLPv2 in the manner indicated in the example.

Acknowledgements

   I thank the IESG, for their usual persistence and attention to
   detail.

References

   [1]   Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
         Location Protocol, Version 2", RFC 2608, July 1999.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   http://www.iana.org/numbers.html

   [4]   Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
         URLs", RFC 2609, July 1999.

   [5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

   [6]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
         1992.









Guttman                     Standards Track                     [Page 8]

RFC 3224             Vendor Extensions for Service          January 2002


Author's Address

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany

   Phone:     [phone]
   Messages:  [phone]
   EMail:    [e-mail]








































Guttman                     Standards Track                     [Page 9]

RFC 3224             Vendor Extensions for Service          January 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Guttman                     Standards Track                    [Page 10]