Document Action: 'OCRA: OATH Challenge-Response Algorithms' to Informational RFC (draft-mraihi-mutual-oath-hotp-variants-14.txt)

[The IESG <[e-mail]>]

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 <[e-mail]> is the document shepherd for this document.
Sean Turner <[e-mail]> 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.