The IESG has approved the following document: - 'OCRA: OATH Challenge-Response Algorithms' (draft-mraihi-mutual-oath-hotp-variants-14.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-mraihi-mutual-oath-hotp-variants/ Technical Summary This document describes an algorithm for challenge-response authentication developed by the "Initiative for Open AuTHentication" (OATH). The specified mechanism is based on the algorithm is based on the HMAC-Based One-Time Password Algorithm (HOTP). Working Group Summary This document was developed outside the IETF, namely in the OATH community. A number of OATH members participate in the IETF KEYPROV working group and brought this work forward to the IETF. Document Quality This document is an AD-sponsored submission and has enjoyed review within the OATH community. Implementations of the specification exist. Personnel Hannes Tschofenig <Hannes.Tschofenig@gmx.net> is the document shepherd for this document. Sean Turner <turners@ieca.com> is the sponsoring Area Director. RFC Editor Note 1) Replace reference to RFC 2279 --> RFC 3629. RFC 2279 was obsoleted. This occurs in 2 places section 5.1 and section 12.1. 2) Section 5.1, replace the following text o T is an 8-byte unsigned integer in big endian (i.e. network byte order) representing the number of time-steps(seconds, minutes, hours or days depending on the specified granularity) since midnight UTC of January 1, 1970. More specificatlly, if the OCRA computation includes a timestamp T, you should first convert your current local time to UTC time; you can then derive the UTC time in the proper format (i.e. seconds, minutes, hours or days elapsed from Epoch time); the size of the time-step is defined in the OCRASuite string With o T is an 8-byte unsigned integer in big endian (i.e. network byte order) representing the number of time-steps(seconds, minutes, hours or days depending on the specified granularity) since midnight UTC of January 1, 1970. More specificatlly, if the OCRA computation includes a timestamp T, you should first convert your current local time to UTC time; you can then derive the UTC time in the proper format (i.e. seconds, minutes, hours or days elapsed from Epoch time); the size of the time-step is specified in the OCRASuite string as described in section 6.3 3) Section 5 - remove repeated word 'section' from the statement below... computation from the secret key K and the DataInput material; CryptoFunction is described in details in section Section 5.2 4) Replace 'digital signature' with 'electronic signature'. There are 4 occurrences in the document. 5) Section 1 - Introduction. Replace the text - Additionally, this specification describes the means to create symmetric key based short digital signatures. Such signatures are variants of challenge-response mode where the data to be signed becomes the challenge. With Additionally, this specification describes the means to create symmetric key based short 'electronic signatures'. Such signatures are variants of challenge-response mode where the data to be signed becomes the challenge or is used to derive the challenge. Note that the term 'electronic signature' and 'signature' are used interchangeably in this document. 6 a) Add reference to RFC6030 (Portable Symmetric Key Container) in section 12.2 [RFC6030] Hoyer, P., Pei, M., and S. Machani, "Portable Symmetric Key Container (PSKC)", RFC 6030, October 2010, <http://www.ietf.org/rfc/rfc6030.txt>. 6 b) Add sentence to section 6 after the following sentence... ...for more sophisticated client-server interactions these values may be negotiated for every transaction. New text- ...for more sophisticated client-server interactions these values may be negotiated for every transaction. The provisioning of OCRA keys and related metadata such as OCRASuite is out of scope for this document. [RFC6030] specifies one key container specification that facilitates provisioning of such data between the client and the server. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
