rfc2847.txt

中、英文RFC文档大全打包下载完全版 .

      Valid-UNP ::= BOOLEAN
                      -- If TRUE, user name/password pair was valid.

4.3.2.  Tokens from GSS_GetMIC and GSS_Wrap

   RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
             PerMsgToken ::=
             -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
             -- ASN.1 structure not required
                     innerMsgToken ANY

             SealedMessage ::=
             -- as emitted by GSS_Wrap and processed by GSS_Unwrap
             -- includes internal, mechanism-defined indicator
             -- of whether or not encrypted
             -- ASN.1 structure not required
                     sealedUserData ANY

   As one can see, there are no mechanism independent prefixes in
   PerMSGToken or SealedMessage, and no explicit mechanism specific
   information. Since LIPKEY does not add any value to GSS_GetMIC and





Eisler                      Standards Track                    [Page 17]

RFC 2847                         LIPKEY                        June 2000


   GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC and
   GSS_Wrap, LIPKEY's PerMsgToken and SealedMessage tokens are exactly
   what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce.

4.4.  Quality of Protection

   LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3,
   does not interpret or alter the QOPs passed to the aforementioned
   routines or received from their complements, GSS_Unwrap, and
   GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3.

5.  Security Considerations

5.1.  Password Management

   LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so
   the risk in this approach is in how the target manages the password
   after it is done with it. The approach should be safe, provided the
   target clears the memory (primary and secondary, such as disk)
   buffers that contained the password, and any hash of the password
   immediately after it has validated the user's password.

5.2.  Certification Authorities

   The initiator must have a list of trusted Certification Authorities
   in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's
   context reply token. If it encounters a certificate signed by an
   unknown and/or untrusted certificate authority, the initiator MUST
   NOT silently accept the certificate. If it does wish to accept the
   certificate, it MUST get confirmation from the user running the
   application that is using GSS-API.

5.3.  HMAC-MD5 and MD5 Weaknesses

   While the MD5 hash algorithm has been found to have weaknesses
   [Dobbertin], the weaknesses do not impact the security of HMAC-MD5
   [Dobbertin].

5.4.  Security of cast5CBC

   The cast5CBC encryption algorithm is relatively new compared to
   established algorithms like triple DES, and RC4. Nonetheless, the
   choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable.
   The cast5CBC algorithm is a 128 bit algorithm that the 256 bit
   cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm
   was judged by the U.S. National Institute of Standards and Technology
   (NIST) to have no known major or minor "security gaps," and to have a
   "high security margin" [AES]. NIST did note some vulnerabilities



Eisler                      Standards Track                    [Page 18]

RFC 2847                         LIPKEY                        June 2000


   related to smart card implementations, but many other algorithms NIST
   analyzed shared the vulnerabilities, and in any case, LIPKEY is by
   definition not aimed at smart cards.

References

   [AES]       Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti,
               J., Roback, E. (Undated, but no later than 1999). "Status
               Report on the First Round of the Development of the
               Advanced Encryption Standard."
               http://csrc.nist.gov/encryption/aes/round1/r1report.htm

   [CCITT]     CCITT (1988). "Recommendation X.208: Specification of
               Abstract Syntax Notation One (ASN.1)."

   [Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent
               Attack," RSA Laboratories' CryptoBytes, Volume 2, Number
               2.
               ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf

   [EFF]       Electronic Frontier Foundation, John Gilmore (Editor)
               (1998). "Cracking Des: Secrets of Encryption Research,
               Wiretap Politics & Chip Design," O'Reilly & Associates,
               ISBN 1565925203.

   [FIPS]      National Institute of Standards and Technology (1995).
               "Secure Hash Standard" (SHA-1).
               http://www.itl.nist.gov/fipspubs/fip180-1.htm

   [IANA]      Internet Assigned Numbers Authority (1999). "Network
               Management Parameters."  http://www.isi.edu/in-
               notes/iana/assignments/smi-numbers

   [PKCS-3]    RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-
               Agreement Standard, Version 1.4."
               ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc

   [PKIX]      Housley, R., Ford, W., Polk, W., Solo, D., "Internet
               X.509 Public Key Infrastructure Certificate and CRL
               Profile", Work in Progress.

   [RFC1831]   Srinivasan, R., "RPC: Remote Procedure Call Protocol
               Specification Version 2", RFC 1831, August 1995.

   [RFC1832]   Srinivasan, R., "XDR: External Data Representation
               Standard", RFC 1832, August 1995.





Eisler                      Standards Track                    [Page 19]

RFC 2847                         LIPKEY                        June 2000


   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
               1964, June 1996.

   [RFC2203]   Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
               Specification", RFC 2203, September 1997.

   [RFC2025]   Adams, C., "The Simple Public-Key GSS-API Mechanism
               (SPKM)", RFC 2025, October 1996.

   [RFC2078]   Linn, J., "Generic Security Service Application Program
               Interface, Version 2", RFC 2078, January 1997.

   [RFC2104]   Krawczyk, H, Bellare, M. and R. Canetti, "HMAC:  Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

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

   [RFC2144]   Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
               May 1997.

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

   [RFC2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
               Specifications Version 2.0", RFC 2437, October 1998.

   [RFC2459]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
               X.509 Public Key Infrastructure Certificate and CRL
               Profile", RFC 2459, January 1999.

   [RFC2612]  Adams, C. and J. Gilchrist, "The CAST-256 Encryption
               Algorithm", RFC 2612, June 1999.

   [RSA-IP]   All statements received by the IETF Secretariat are places
               on-line in http://www.ietf.org/ipr.html.  Please check
               this web page to see any IPR information received about
               this and other technology.

   [Sandberg]  Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
               B. (1985). "Design and Implementation of the Sun Network
               Filesystem,"  Proceedings of the 1985 Summer USENIX
               Technical Conference.




Eisler                      Standards Track                    [Page 20]

RFC 2847                         LIPKEY                        June 2000


   [Schneier]  Schneier, B. (1996). "Applied Cryptography," John Wiley &
               Sons, Inc., ISBN 0-471-11709-9.

   [Young]     Young, E.A. (1997). Collected timing results from the
               SSLeay source code distribution.

Acknowledgments

   The author thanks and acknowledges:

   *    Jack Kabat for his patient explanation of the intricacies of
        SPKM, excellent suggestions, and review comments.

   *    Denis Pinkas for his review comments.

   *    Carlisle Adams for his review comments.

   *    John Linn for his review comments.

   *    Martin Rex for his review comments.

   *    This memorandum includes ASN.1 definitions for GSS-API tokens
        from RFC 2078, which was authored by John Linn.

   *    This memorandum includes ASN.1 definitions and other text from
        the SPKM definition in RFC 2025, which was authored by Carlisle
        Adams.

Author's Address

   Address comments related to this memorandum to:

   [e-mail]

   Mike Eisler
   Zambeel
   5565 Wilson Road
   Colorado Springs, CO 80919

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










Eisler                      Standards Track                    [Page 21]

RFC 2847                         LIPKEY                        June 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Eisler                      Standards Track                    [Page 22]