rfc4173.txt

一个学习iSCSI协议的文档

RFC 4173                  iSCSI Bootstrapping             September 2005


8.  Security Considerations

   The security discussion is centered around securing the communication
   involved in the iSCSI boot process.

   However, the issue of applying credentials to a boot image loaded
   through the iSCSI boot mechanism is outside the scope of this
   document.  One key difference between the iSCSI boot mechanism and
   BOOTP-based image loading is the fact that the identity of a boot
   image may not be known when the Boot stage starts.  The identity of
   certain boot images and their locations are known only after the
   contents of a boot disk exposed by the iSCSI boot service are
   examined.  Furthermore, images themselves may recursively load other
   images based on both hardware configurations and user input.
   Consequently, a practical way to verify loaded boot images is to make
   sure that each image loading software verifies the image to be loaded
   using a mechanism of their choice.

   The considerations involved in designing a security architecture for
   the iSCSI boot process include configuration, deployment, and
   provisioning issues apart from typical security considerations.
   Enabling iSCSI boot creates a critical operational dependence on an
   external system with obvious security implications, and thus
   administrator awareness of this enablement is extremely important.
   Therefore, iSCSI boot SHOULD NOT be enabled or put high in the boot
   order without an explicit administrative action.

   In all phases of the boot process, a client must ensure that a server
   is authorized to send it certain information.  This means that the
   authenticated identity of a server must have an authorization
   indication.  A list of authorized servers can be pre-configured into
   a client, or the list can be downloaded in an authenticated form from
   a prior stage in the boot process.

   The software stage SHOULD NOT be involved in a secure iSCSI boot
   process, as this would add the additional complexity of trying to
   secure the process of loading the software necessary to run the later
   stages of iSCSI boot.  Authentication and integrity protection of
   downloaded boot software has proven to be difficult and complex due
   to administrative issues and limitations of the BIOS environment.  It
   is therefore assumed that all the necessary software is resident on
   the iSCSI boot client.

   If the DHCP stage is implemented using the DHCP protocol, the iSCSI
   boot client SHOULD implement the DHCP authentication ([Droms01],
   [Droms02] for IPv6).  In this case, an administration interface
   SHOULD be provided for the configuration of the DHCP authentication
   credentials, both when the network interface is on the motherboard



Sarkar, et al.              Standards Track                     [Page 7]

RFC 4173                  iSCSI Bootstrapping             September 2005


   and when it is removable.  Note that DHCP authentication
   ([Droms01],[Droms02] for IPv6) is focused on intra-domain
   authentication, which is assumed to be enough for iSCSI boot
   scenarios.  In the context of the secure iSCSI boot process, the
   reply from the DHCP server in the DHCP stage SHOULD include the
   serverName in IPv4 (or IPv6) format to avoid reliance on a DNS server
   (for resolving names) or a Discovery Service entity (to look up
   targetnames).  This reduces the number of entities involved in the
   secure iSCSI boot process.

   If the Discovery Service stage is implemented using SLP, the iSCSI
   boot client SHOULD provide IPsec support (OPTIONAL to use) for the
   SLP protocol, as defined in [Bakke02] and [Aboba03].  If the
   Discovery Service stage is implemented using iSNS, the iSCSI boot
   client SHOULD provide IPsec support (OPTIONAL to use) for the iSNS
   protocol, as defined in [Tseng03] and [Aboba03].  When iSNS or SLP
   are used to distribute security policy or configuration information,
   at a minimum, per-packet data origin authentication, integrity, and
   replay protection SHOULD be used to protect the discovery protocol.

   For the final communication between the iSCSI boot client and the
   iSCSI boot server in the Boot stage, IPsec and in-band authentication
   SHOULD be implemented according to the guidelines in the main iSCSI
   draft [Satran02] and [Aboba03].  Due to memory constraints, it is
   expected that iSCSI boot clients will only support the pre-shared key
   authentication in IKE.  Where the host IP address is assigned
   dynamically, IKE main mode SHOULD NOT be used, as explained in
   [Satran02] and [Aboba03].  Regardless of the way parameters in
   previous stages (DHCP, SLP, iSNS) were obtained (securely or not),
   the iSCSI boot session is vulnerable as any iSCSI session (see
   [Satran02] and [Aboba03] for iSCSI security threats).  Therefore,
   security for this session SHOULD be configured and used according to
   [Satran02] and [Aboba03] guidelines.

   Note that if a boot image inherits an iSCSI session from a previously
   loaded boot image, it also inherits the security properties of the
   iSCSI session.

Acknowledgements

   We wish to thank John Hufferd for taking the initiative to form the
   iSCSI boot team.  We also wish to thank Doug Otis, Julian Satran,
   Bernard Aboba, David Robinson, Mark Bakke, Ofer Biran, and
   Mallikarjun Chadalapaka for helpful suggestions and pointers
   regarding the draft document.






Sarkar, et al.              Standards Track                     [Page 8]

RFC 4173                  iSCSI Bootstrapping             September 2005


Normative References

   [Aboba03]      Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
                  Travostino, "Securing Block Storage Protocols over
                  IP", RFC 3723, April 2004.

   [Alexander93]  Alexander, S. and R. Droms, "DHCP Options and BOOTP
                  Vendor Extensions", RFC 2132, March 1997.

   [Bakke02]      Bakke, M., Hufferd, J., Voruganti, K., Krueger, M.,
                  and T. Sperry, "Finding Internet Small Computer
                  Systems Interface (iSCSI) Targets and Name Servers by
                  Using Service Location Protocol version 2 (SLPv2)",
                  RFC 4018, April 2005.

   [Bakke04]      Bakke, M., "String Profile for Internet Small Computer
                  Systems Interface (iSCSI) Names", RFC 3722, April
                  2004.

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

   [Croft85]      Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC
                  951, September 1985.

   [Droms93]      Droms, R., "Interoperation Between DHCP and BOOTP",
                  RFC 1534, October 1993.

   [Droms97]      Droms, R., "Dynamic Host Configuration Protocol", RFC
                  2131, March 1997.

   [Droms01]      Droms, R. and W. Arbaugh, "Authentication for DHCP
                  Messages", RFC 3118, June 2001.

   [Droms02]      Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                  C., and M. Carney, "Dynamic Host Configuration
                  Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

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

   [Hinden99]     Hinden, R., Carpenter, B., and L. Masinter, "Format
                  for Literal IPv6 Addresses in URL's", RFC 2732,
                  December 1999.






Sarkar, et al.              Standards Track                     [Page 9]

RFC 4173                  iSCSI Bootstrapping             September 2005


   [Lee98]        Berners-Lee, T., Fielding, R., and L. Masinter,
                  "Uniform Resource Identifiers (URI): Generic Syntax",
                  RFC 2396, August 1998.

   [Reynolds93]   Reynolds, J., "BOOTP Vendor Information Extensions",
                  RFC 1497, August 1993.

   [Satran02]     Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka,
                  M., and E. Zeidner, "Internet Small Computer Systems
                  Interface (iSCSI)", RFC 3720, April 2004.

   [Tseng03]      Tseng, J., Gibbons, K., Travostino, F., Du Laney, C.,
                  and J. Souza, "Internet Storage Name Service (iSNS)",
                  RFC 4171, April 2005.

   [Yergeau98]    Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", STD 63, RFC 3629, November 2003.

   [Wimer93]      Wimer, W., "Clarifications and Extensions for the
                  Bootstrap Protocol", RFC 1542, October 1993.

Informative References

   [Brownell96]   Brownell, D., "Dynamic RARP Extensions for Automatic
                  Network Address Acquisition", RFC 1931, April 1996.

   [Finlayson84]  Finlayson, R., Mann, T., Mogul, J., and M. Theimer,
                  "Reverse Address Resolution Protocol", STD 38, RFC
                  903, June 1984.

   [Sollins81]    Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
                  RFC 1350, July 1992.



















Sarkar, et al.              Standards Track                    [Page 10]

RFC 4173                  iSCSI Bootstrapping             September 2005


Authors' Addresses

   Prasenjit Sarkar
   IBM Almaden Research Center
   650 Harry Road
   San Jose, CA 95120, USA

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


   Duncan Missimer
   Hewlett-Packard Company
   10955 Tantau Ave
   Cupertino, CA 95014, USA

   EMail: [e-mail]


   Constantine Sapuntzakis
   Stanford University
   353 Serra Hall #407
   Stanford, CA 94305, USA

   EMail: [e-mail]


























Sarkar, et al.              Standards Track                    [Page 11]

RFC 4173                  iSCSI Bootstrapping             September 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

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







Sarkar, et al.              Standards Track                    [Page 12]