|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 2104 (1997)
|
|
Title:
|
HMAC: Keyed-Hashing for Message Authentication, IETF RFC, February 1997.
|
|
|
2.
|
Status of approval:
|
|
|
Informative RFC approved 1997 by IESG (Internet Engineering Steering Group).
|
|
3.
|
Justification for the specific reference:
|
|
|
Draft Rec. X.cso refers to HMAC: Keyed-Hashing for Message Authentication, IETF RFC, February 1997.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2104
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
Proposed Standard
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Proposed Standard
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
References within the referenced RFCs are listed under item (8).
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
[ANSI] ANSI X9.9, "American National Standard for Financial/
Institution Message Authentication (Wholesale)," American/
Bankers Association, 1981. Revised 1986./
/
[Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August/
1995./
/
[BCK1] M. Bellare, R. Canetti, and H. Krawczyk,/
"Keyed Hash Functions and Message Authentication",/
Proceedings of Crypto'96, LNCS 1109, pp. 1-15./
(http://www.research.ibm.com/security/keyed-md5.html)/
/
[BCK2] M. Bellare, R. Canetti, and H. Krawczyk,/
"Pseudorandom Functions Revisited: The Cascade Construction",/
Proceedings of FOCS'96./
/
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",/
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996./
http://www.rsa.com/rsalabs/pubs/cryptobytes.html/
/
[PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash/
functions", Advances in Cryptology -- CRYPTO'95 Proceedings,/
Lecture Notes in Computer Science, Springer-Verlag Vol.963,/
1995, pp. 1-14./
/
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",/
RFC 1321, April 1992./
[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,/
1982./
/
[RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A/
strengthened version of RIPEMD", Fast Software Encryption,/
LNCS Vol 1039, pp. 71-82./
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/./
/
[SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995./
/
[Tsu] G. Tsudik, "Message authentication with one-way hash/
functions", In Proceedings of Infocom'92, May 1992./
(Also in "Access Control and Policy Enforcement in/
Internetworks", Ph.D. Dissertation, Computer Science/
Department, University of Southern California, April 1991.)/
/
[VW] P. van Oorschot and M. Wiener, "Parallel Collision/
Search with Applications to Hash Functions and Discrete/
Logarithms", Proceedings of the 2nd ACM Conf. Computer and/
Communications Security, Fairfax, VA, November 1994./
/
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
Other: If the study group decides to make the reference to the RFC, the reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic". Normative references should not be made to RFCs that are not standards, for example, "Informational" and "Experimental" RFCs.
|
|
