-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathrfc6287.txt
2131 lines (1461 loc) · 76.2 KB
/
rfc6287.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Internet Engineering Task Force (IETF) D. M'Raihi
Request for Comments: 6287 Verisign, Inc.
Category: Informational J. Rydell
ISSN: 2070-1721 Portwise, Inc.
S. Bajaj
Symantec Corp.
S. Machani
Diversinet Corp.
D. Naccache
Ecole Normale Superieure
June 2011
OCRA: OATH Challenge-Response Algorithm
Abstract
This document describes an algorithm for challenge-response
authentication developed by the Initiative for Open Authentication
(OATH). The specified mechanisms leverage the HMAC-based One-Time
Password (HOTP) algorithm and offer one-way and mutual
authentication, and electronic signature capabilities.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6287.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
M'Raihi, et al. Informational [Page 1]
RFC 6287 OCRA June 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. Notation and Terminology ........................................3
3. Algorithm Requirements ..........................................3
4. OCRA Background .................................................4
4.1. HOTP Algorithm .............................................4
5. Definition of OCRA ..............................................5
5.1. DataInput Parameters .......................................5
5.2. CryptoFunction .............................................7
6. The OCRASuite ...................................................8
6.1. Algorithm ..................................................9
6.2. CryptoFunction .............................................9
6.3. DataInput ..................................................9
6.4. OCRASuite Examples ........................................10
7. Algorithm Modes for Authentication .............................10
7.1. One-Way Challenge-Response ................................11
7.2. Mutual Challenge-Response .................................12
7.3. Algorithm Modes for Signature .............................13
7.3.1. Plain Signature ....................................13
7.3.2. Signature with Server Authentication ...............14
8. Security Considerations ........................................16
8.1. Security Analysis of OCRA .................................16
8.2. Implementation Considerations .............................17
9. Conclusion .....................................................18
10. Acknowledgements ..............................................18
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative References ...................................19
Appendix A. Reference Implementation ..............................20
Appendix B. Test Vectors Generation ...............................26
Appendix C. Test Vectors ..........................................33
C.1. One-Way Challenge Response .................................34
C.2. Mutual Challenge-Response ..................................35
C.3. Plain Signature ............................................37
M'Raihi, et al. Informational [Page 2]
RFC 6287 OCRA June 2011
1. Introduction
The Initiative for Open Authentication (OATH) [OATH] has identified
several use cases and scenarios that require an asynchronous variant
to accommodate users who do not want to maintain a synchronized
authentication system. A commonly accepted method for this is to use
a challenge-response scheme.
Such a challenge-response mode of authentication is widely adopted in
the industry. Several vendors already offer software applications
and hardware devices implementing challenge-response -- but each of
those uses vendor-specific proprietary algorithms. For the benefits
of users there is a need for a standardized challenge-response
algorithm that allows multi-sourcing of token purchases and
validation systems to facilitate the democratization of strong
authentication.
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.
2. Notation and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Algorithm Requirements
This section presents the main requirements that drove this algorithm
design. A lot of emphasis was placed on flexibility and usability,
under the constraints and specificity of the HMAC-based One-Time
Password (HOTP) algorithm [RFC4226] and hardware token capabilities.
R1 - The algorithm MUST support challenge-response-based
authentication.
R2 - The algorithm MUST be capable of supporting symmetric key-based
short electronic signatures. Essentially, this is a variation of
challenge-response where the challenge is derived from the data that
needs to be signed.
R3 - The algorithm MUST be capable of supporting server
authentication, whereby the user can verify that he/she is talking to
a trusted server.
M'Raihi, et al. Informational [Page 3]
RFC 6287 OCRA June 2011
R4 - The algorithm SHOULD use HOTP [RFC4226] as a key building block.
R5 - The length and format of the input challenge SHOULD be
configurable.
R6 - The output length and format of the generated response SHOULD be
configurable.
R7 - The challenge MAY be generated with integrity checking (e.g.,
parity bits). This will allow tokens with pin pads to perform simple
error checking when the user enters the challenge value into a token.
R8 - There MUST be a unique secret (key) for each token/soft token
that is shared between the token and the authentication server. The
keys MUST be randomly generated or derived using a key derivation
algorithm.
R9 - The algorithm MAY enable additional data attributes such as a
timestamp or session information to be included in the computation.
These data inputs MAY be used individually or all together.
4. OCRA Background
OATH introduced the HOTP algorithm as a first open, freely available
building block towards strengthening authentication for end-users in
a variety of applications. One-time passwords are very efficient at
solving specific security issues thanks to the dynamic nature of OTP
computations.
After carefully analyzing different use cases, OATH came to the
conclusion that providing for extensions to the HOTP algorithms was
important. A very natural extension is to introduce a challenge mode
for computing HOTP values based on random questions. Equally
beneficial is being able to perform mutual authentication between two
parties, or short-signature computation for authenticating
transaction to improve the security of e-commerce applications.
4.1. HOTP Algorithm
The HOTP algorithm, as defined in [RFC4226], is based on an
increasing counter value and a static symmetric key known only to the
prover and verifier parties.
As a reminder:
HOTP(K,C) = Truncate(HMAC-SHA1(K,C))
where Truncate represents the function that converts an HMAC-SHA-1
value into an HOTP value.
M'Raihi, et al. Informational [Page 4]
RFC 6287 OCRA June 2011
We refer the reader to [RFC4226] for the full description and further
details on the rationale and security analysis of HOTP.
The present document describes the different variants based on
similar constructions as HOTP.
5. Definition of OCRA
The OATH Challenge-Response Algorithm (OCRA) is a generalization of
HOTP with variable data inputs not solely based on an incremented
counter and secret key values.
The definition of OCRA requires a cryptographic function, a key K and
a set of DataInput parameters. This section first formally
introduces OCRA and then introduces the definitions and default
values recommended for all parameters.
In a nutshell,
OCRA = CryptoFunction(K, DataInput)
where:
o K: a shared secret key known to both parties
o DataInput: a structure that contains the concatenation of the
various input data values defined in details in section 5.1
o CryptoFunction: this is the function performing the OCRA
computation from the secret key K and the DataInput material;
CryptoFunction is described in details in Section 5.2
5.1. DataInput Parameters
This structure is the concatenation over byte array of the OCRASuite
value as defined in section 6 with the different parameters used in
the computation, save for the secret key K.
DataInput = {OCRASuite | 00 | C | Q | P | S | T} where:
o OCRASuite is a value representing the suite of operations to
compute an OCRA response
o 00 is a byte value used as a separator
M'Raihi, et al. Informational [Page 5]
RFC 6287 OCRA June 2011
o C is an unsigned 8-byte counter value processed high-order bit
first, and MUST be synchronized between all parties; It loops
around from "{Hex}0" to "{Hex}FFFFFFFFFFFFFFFF" and then starts
over at "{Hex}0". Note that 'C' is optional for all OCRA modes
described in this document.
o Q, mandatory, is a 128-byte list of (concatenated) challenge
question(s) generated by the parties; if Q is less than 128 bytes,
then it should be padded with zeroes to the right
o P is a hash (SHA-1 [RFC3174], SHA-256 and SHA-512 [SHA2] are
supported) value of PIN/password that is known to all parties
during the execution of the algorithm; the length of P will depend
on the hash function that is used
o S is a UTF-8 [RFC3629] encoded string of length up to 512 bytes
that contains information about the current session; the length of
S is defined in the OCRASuite string
o T is an 8-byte unsigned integer in big-endian order (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 [UT]. More specifically, 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
When computing a response, the concatenation order is always the
following:
C |
OTHER-PARTY-GENERATED-CHALLENGE-QUESTION |
YOUR-GENERATED-CHALLENGE-QUESTION |
P| S | T
If a value is empty (i.e., a certain input is not used in the
computation) then the value is simply not represented in the string.
The counter on the token or client MUST be incremented every time a
new computation is requested by the user. The server's counter value
MUST only be incremented after a successful OCRA authentication.
M'Raihi, et al. Informational [Page 6]
RFC 6287 OCRA June 2011
5.2. CryptoFunction
The default CryptoFunction is HOTP-SHA1-6, i.e., the default mode of
computation for OCRA is HOTP with the default 6-digit dynamic
truncation and a combination of DataInput values as the message to
compute the HMAC-SHA1 digest.
We denote t as the length in decimal digits of the truncation output.
For instance, if t = 6, then the output of the truncation is a
6-digit (decimal) value.
We define the HOTP family of functions as an extension to HOTP:
1. HOTP-H-t: these are the different possible truncated versions of
HOTP, using the dynamic truncation method for extracting an HOTP
value from the HMAC output
2. We will denote HOTP-H-t as the realization of an HOTP function
that uses an HMAC function with the hash function H, and the
dynamic truncation as described in [RFC4226] to extract a t-digit
value
3. t=0 means that no truncation is performed and the full HMAC value
is used for authentication purposes
We list the following preferred modes of computation, where * denotes
the default CryptoFunction:
o HOTP-SHA1-4: HOTP with SHA-1 as the hash function for HMAC and a
dynamic truncation to a 4-digit value; this mode is not
recommended in the general case, but it can be useful when a very
short authentication code is needed by an application
o HOTP-SHA1-6: HOTP with SHA-1 as the hash function for HMAC and a
dynamic truncation to a 6-digit value
o HOTP-SHA1-8: HOTP with SHA-1 as the hash function for HMAC and a
dynamic truncation to an 8-digit value
o HOTP-SHA256-6: HOTP with SHA-256 as the hash function for HMAC and
a dynamic truncation to a 6-digit value
o HOTP-SHA512-6: HOTP with SHA-512 as the hash function for HMAC and
a dynamic truncation to a 6-digit value
M'Raihi, et al. Informational [Page 7]
RFC 6287 OCRA June 2011
This table summarizes all possible values for the CryptoFunction:
+---------------+--------------------+-------------------------+
| Name | HMAC Function Used | Size of Truncation (t) |
+---------------+--------------------+-------------------------+
| HOTP-SHA1-t | HMAC-SHA1 | 0 (no truncation), 4-10 |
| HOTP-SHA256-t | HMAC-SHA256 | 0 (no truncation), 4-10 |
| HOTP-SHA512-t | HMAC-SHA512 | 0 (no truncation), 4-10 |
+---------------+--------------------+-------------------------+
Table 1: CryptoFunction Table
6. The OCRASuite
An OCRASuite value is a text string that captures one mode of
operation for OCRA, completely specifying the various options for
that computation. An OCRASuite value is represented as follows:
<Algorithm>:<CryptoFunction>:<DataInput>
The OCRASuite value is the concatenation of three sub-components that
are described below. Some example OCRASuite strings are described in
Section 6.4.
The client and server need to agree on one or two values of
OCRASuite. These values may be agreed upon at the time of token
provisioning or, 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.
Note that for Mutual Challenge-Response or Signature with Server
Authentication modes, the client and server will need to agree on two
values of OCRASuite -- one for server computation and another for
client computation.
M'Raihi, et al. Informational [Page 8]
RFC 6287 OCRA June 2011
6.1. Algorithm
Description: Indicates the version of OCRA.
Values: OCRA-v where v represents the version number (e.g., 1, 2).
This document specifies version 1 of OCRA.
6.2. CryptoFunction
Description: Indicates the function used to compute OCRA values
Values: Permitted values are described in Section 5.2.
6.3. DataInput
Description: This component of the OCRASuite string captures the list
of valid inputs for that computation; [] indicates a value is
optional:
[C] | QFxx | [PH | Snnn | TG] : Challenge-Response computation
[C] | QFxx | [PH | TG] : Plain Signature computation
Each input that is used for the computation is represented by a
single letter (except Q), and they are separated by a hyphen.
The input for challenge is further qualified by the formats supported
by the client for challenge question(s). Supported values can be:
+------------------+-------------------+
| Format (F) | Up to Length (xx) |
+------------------+-------------------+
| A (alphanumeric) | 04-64 |
| N (numeric) | 04-64 |
| H (hexadecimal) | 04-64 |
+------------------+-------------------+
Table 2: Challenge Format Table
The default challenge format is N08, numeric and up to 8 digits.
The input for P is further qualified by the hash function used for
the PIN/password. Supported values for hash function can be:
Hash function (H) - SHA1, SHA256, SHA512.
The default hash function for P is SHA1.
M'Raihi, et al. Informational [Page 9]
RFC 6287 OCRA June 2011
The input for S is further qualified by the length of the session
data in bytes. The client and server could agree to any length but
the typical values are:
Length (nnn) - 064, 128, 256, and 512.
The default length is 064 bytes.
The input for timestamps is further qualified by G, size of the time-
step. G can be specified in number of seconds, minutes, or hours:
+--------------------+------------------------------+
| Time-Step Size (G) | Examples |
+--------------------+------------------------------+
| [1-59]S | number of seconds, e.g., 20S |
| [1-59]M | number of minutes, e.g., 5M |
| [0-48]H | number of hours, e.g., 24H |
+--------------------+------------------------------+
Table 3: Time-step Size Table
Default value for G is 1M, i.e., time-step size is one minute and the
T represents the number of minutes since epoch time [UT].
6.4. OCRASuite Examples
Here are some examples of OCRASuite strings:
o "OCRA-1:HOTP-SHA512-8:C-QN08-PSHA1" means version 1 of OCRA with
HMAC-SHA512 function, truncated to an 8-digit value, using the
counter, a random challenge, and a SHA1 digest of the PIN/password
as parameters. It also indicates that the client supports only
numeric challenge up to 8 digits in length
o "OCRA-1:HOTP-SHA256-6:QA10-T1M" means version 1 of OCRA with HMAC-
SHA256 function, truncated to a 6-digit value, using a random
alphanumeric challenge up to 10 characters in length and a
timestamp in number of minutes since epoch time
o "OCRA-1:HOTP-SHA1-4:QH8-S512" means version 1 of OCRA with HMAC-
SHA1 function, truncated to a 4-digit value, using a random
hexadecimal challenge up to 8 nibbles and a session value of 512
bytes
7. Algorithm Modes for Authentication
This section describes the typical modes in which the above defined
computation can be used for authentication.
M'Raihi, et al. Informational [Page 10]
RFC 6287 OCRA June 2011
7.1. One-Way Challenge-Response
A challenge-response is a security mechanism in which the verifier
presents a question (challenge) to the prover, who must provide a
valid answer (response) to be authenticated.
To use this algorithm for a one-way challenge-response, the verifier
will communicate a challenge value (typically randomly generated) to
the prover. The prover will use the challenge in the computation as
described above. The prover then communicates the response to the
verifier to authenticate.
Therefore in this mode, the typical data inputs will be:
C - Counter, optional.
Q - Challenge question, mandatory, supplied by the verifier.
P - Hashed version of PIN/password, optional.
S - Session information, optional.
T - Timestamp, optional.
The diagram below shows the message exchange between the client
(prover) and the server (verifier) to complete a one-way challenge-
response authentication.
It is assumed that the client and server have a pre-shared key K that
is used for the computation.
CLIENT SERVER
(PROVER) VERIFIER)
| |
| Verifier sends challenge to prover |
| Challenge = Q |
|<---------------------------------------|
| |
| Prover Computes Response |
| R = OCRA(K, {[C] | Q | [P | S | T]}) |
| Prover sends Response = R |
|--------------------------------------->|
| |
| Verifier Validates Response |
| If Response is valid, Server sends OK |
| If Response is not, Server sends NOK |
|<---------------------------------------|
| |
M'Raihi, et al. Informational [Page 11]
RFC 6287 OCRA June 2011
7.2. Mutual Challenge-Response
Mutual challenge-response is a variation of one-way challenge-
response where both the client and server mutually authenticate each
other.
To use this algorithm, the client will first send a random client-
challenge to the server. The server computes the server-response and
sends it to the client along with a server-challenge.
The client will first verify the server-response to be assured that
it is talking to a valid server. It will then compute the client-
response and send it to the server to authenticate. The server
verifies the client-response to complete the two-way authentication
process.
In this mode there are two computations: client-response and server-
response. There are two separate challenge questions, generated by
both parties. We denote these challenge questions Q1 and Q2.
Typical data inputs for server-response computation will be:
C - Counter, optional.
QC - Challenge question, mandatory, supplied by the client.
QS - Challenge question, mandatory, supplied by the server.
S - Session information, optional.
T - Timestamp, optional.
Typical data inputs for client-response computation will be:
C - Counter, optional.
QS - Challenge question, mandatory, supplied by the server.
QC - Challenge question, mandatory, supplied by the client.
P - Hashed version of PIN/password, optional.
S - Session information, optional.
T - Timestamp, optional.
M'Raihi, et al. Informational [Page 12]
RFC 6287 OCRA June 2011
The following diagram shows the messages that are exchanged between
the client and the server to complete a two-way mutual challenge-
response authentication.
It is assumed that the client and server have a pre-shared key K (or
pair of keys if using dual-key mode of computation) that is used for
the computation.
CLIENT SERVER
(PROVER) (VERIFIER)
| |
| 1. Client sends client-challenge |
| QC = Client-challenge |
|------------------------------------------------->|
| |
| 2. Server computes server-response |
| and sends server-challenge |
| RS = OCRA(K, [C] | QC | QS | [S | T]) |
| QS = Server-challenge |
| Response = RS, QS |
|<-------------------------------------------------|
| |
| 3. Client verifies server-response |
| and computes client-response |
| OCRA(K, [C] | QC | QS | [S | T]) != RS -> STOP |
| RC = OCRA(K, [C] | QS | QC | [P | S | T]) |
| Response = RC |
|------------------------------------------------->|
| |
| 4. Server verifies client-response |
| OCRA(K, [C] | QS | QC | [P|S|T]) != RC -> STOP |
| Response = OK |
|<-------------------------------------------------|
| |
7.3. Algorithm Modes for Signature
In this section we describe the typical modes in which the above
defined computation can be used for electronic signatures.
7.3.1. Plain Signature
To use this algorithm in plain signature mode, the server will
communicate a signature-challenge value to the client (signer). The
signature-challenge is either the data to be signed or derived from
the data to be signed using a hash function, for example.
M'Raihi, et al. Informational [Page 13]
RFC 6287 OCRA June 2011
The client will use the signature-challenge in the computation as
described above. The client then communicates the signature value
(response) to the server to authenticate.
Therefore in this mode, the data inputs will be:
C - Counter, optional.
QS - Signature-challenge, mandatory, supplied by the server.
P - Hashed version of PIN/password, optional.
T - Timestamp, optional.
The picture below shows the messages that are exchanged between the
client (prover) and the server (verifier) to complete a plain
signature operation.
It is assumed that the client and server have a pre-shared key K that
is used for the computation.
CLIENT SERVER
(PROVER) (VERIFIER)
| |
| Verifier sends signature-challenge |
| Challenge = QS |
|<------------------------------------------|
| |
| Client Computes Response |
| SIGN = OCRA(K, [C] | QS | [P | T]) |
| Response = SIGN |
|------------------------------------------>|
| |
| Verifier Validates Response |
| Response = OK |
|<------------------------------------------|
| |
7.3.2. Signature with Server Authentication
This mode is a variation of the plain signature mode where the client
can first authenticate the server before generating a electronic
signature.
To use this algorithm, the client will first send a random client-
challenge to the server. The server computes the server-response and
sends it to the client along with a signature-challenge.
M'Raihi, et al. Informational [Page 14]
RFC 6287 OCRA June 2011
The client will first verify the server-response to authenticate that
it is talking to a valid server. It will then compute the signature
and send it to the server.
In this mode there are two computations: client-signature and server-
response.
Typical data inputs for server-response computation will be:
C - Counter, optional.
QC - Challenge question, mandatory, supplied by the client.
QS - Signature-challenge, mandatory, supplied by the server.
T - Timestamp, optional.
Typical data inputs for client-signature computation will be:
C - Counter, optional.
QC - Challenge question, mandatory, supplied by the client.
QS - Signature-challenge, mandatory, supplied by the server.
P - Hashed version of PIN/password, optional.
T - Timestamp, optional.
The diagram below shows the messages that are exchanged between the
client and the server to complete a signature with server
authentication transaction.
It is assumed that the client and server have a pre-shared key K (or
pair of keys if using dual-key mode of computation) that is used for
the computation.
M'Raihi, et al. Informational [Page 15]
RFC 6287 OCRA June 2011
CLIENT SERVER
(PROVER) VERIFIER)
| |
| 1. Client sends client-challenge |
| QC = Client-challenge |
|-------------------------------------------------->|
| |
| 2. Server computes server-response |
| and sends signature-challenge |
| RS = OCRA(K, [C] | QC | QS | [T]) |
| QS = signature-challenge |
| Response = RS, QS |
|<--------------------------------------------------|
| |
| 3. Client verifies server-response |
| and computes signature |
| OCRA(K, [C] | QC | QS | [T]) != RS -> STOP |
| SIGN = OCRA( K, [C] | QS | QC | [P | T]) |
| Response = SIGN |
|-------------------------------------------------->|
| |
| 4. Server verifies Signature |
| OCRA(K, [C] | QS | QC | [P|T]) != SIGN -> STOP |
| Response = OK |
|<--------------------------------------------------|
| |
8. Security Considerations
Any algorithm is only as secure as the application and the
authentication protocols that implement it. Therefore, this section
discusses the critical security requirements that our choice of
algorithm imposes on the authentication protocol and validation
software.
8.1. Security Analysis of OCRA
The security and strength of this algorithm depend on the properties
of the underlying building block HOTP, which is a construction based
on HMAC [RFC2104] using SHA-1 [RFC3174] (or SHA-256 or SHA-512
[SHA2]) as the hash function.
The conclusion of the security analysis detailed in [RFC4226] is
that, for all practical purposes, the outputs of the dynamic
truncation on distinct counter inputs are uniformly and independently
distributed strings.
M'Raihi, et al. Informational [Page 16]
RFC 6287 OCRA June 2011
The analysis demonstrates that the best possible attack against the
HOTP function is the brute force attack.
8.2. Implementation Considerations
IC1 - In the authentication mode, the client MUST support two-factor
authentication, i.e., the communication and verification of something
you know (secret code such as a password, pass phrase, PIN code,
etc.) and something you have (token). The secret code is known only
to the user and usually entered with the Response value for
authentication purpose (two-factor authentication). Alternatively,
instead of sending something you know to the server, the client may
use a hash of the password or PIN code in the computation itself,
thus implicitly enabling two-factor authentication.
IC2 - Keys SHOULD be of the length of the CryptoFunction output to
facilitate interoperability.
IC3 - Keys SHOULD be chosen at random or using a cryptographically
strong pseudo-random generator properly seeded with a random value.
We RECOMMEND following the recommendations in [RFC4086] for all
pseudo-random and random generations. The pseudo-random numbers used
for generating the keys SHOULD successfully pass the randomness test
specified in [CN].
IC4 - Challenge questions SHOULD be 20-byte values and MUST be at
least t-byte values where t stands for the digit-length of the OCRA
truncation output.
IC5 - On the client side, the keys SHOULD be embedded in a tamper-
resistant device or securely implemented in a software application.
Additionally, by embedding the keys in a hardware device, you also
have the advantage of improving the flexibility (mobility) of the
authentication system.
IC6 - All the communications SHOULD take place over a secure channel,
e.g., SSL/TLS [RFC5246], IPsec connections.
IC7 - OCRA, when used in mutual authentication mode or in signature
with server authentication mode, MAY use dual-key mode -- i.e., there
are two keys that are shared between the client and the server. One
shared key is used to generate the server response on the server side
and to verify it on the client side. The other key is used to create
the response or signature on the client side and to verify it on the
server side.
M'Raihi, et al. Informational [Page 17]
RFC 6287 OCRA June 2011
IC8 - We recommend that implementations MAY use the session
information, S, as an additional input in the computation. For
example, S could be the session identifier from the TLS session.
This will mitigate against certain types of man-in-the-middle
attacks. However, this will introduce the additional dependency that
first of all the prover needs to have access to the session
identifier to compute the response and the verifier will need access
to the session identifier to verify the response. [RFC5056] contains
a relevant discussion of using Channel Bindings to Secure Channels.
IC9 - In the signature mode, whenever the counter or time (defined as
optional elements) are not used in the computation, there might be a
risk of replay attack and the implementers should carefully consider
this issue in the light of their specific application requirements
and security guidelines. The server SHOULD also provide whenever
possible a mean for the client (if able) to verify the validity of
the signature challenge.
IC10 - We also RECOMMEND storing the keys securely in the validation
system, and more specifically, encrypting them using tamper-resistant
hardware encryption and exposing them only when required: for
example, the key is decrypted when needed to verify an OCRA response,
and re-encrypted immediately to limit exposure in the RAM for a short
period of time. The key store MUST be in a secure area, to avoid as
much as possible direct attack on the validation system and secrets
database. Particularly, access to the key material should be limited
to programs and processes required by the validation system only.
9. Conclusion
This document introduced several variants of HOTP for challenge-
response-based authentication and short signature-like computations.
The OCRASuite provides for an easy integration and support of
different flavors within an authentication and validation system.
Finally, OCRA should enable mutual authentication both in connected
and off-line modes, with the support of different response sizes and
mode of operations.
10. Acknowledgements