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
1001
1002
1003
1004
1005
|
<pre>Network Working Group A. Niemi
Request for Comments: 3310 Nokia
Category: Informational J. Arkko
V. Torvinen
Ericsson
September 2002
<span class="h1">Hypertext Transfer Protocol (HTTP) Digest Authentication</span>
<span class="h1">Using Authentication and Key Agreement (AKA)</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo specifies an Authentication and Key Agreement (AKA) based
one-time password generation mechanism for Hypertext Transfer
Protocol (HTTP) Digest access authentication. The HTTP
Authentication Framework includes two authentication schemes: Basic
and Digest. Both schemes employ a shared secret based mechanism for
access authentication. The AKA mechanism performs user
authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks. AKA is a challenge-
response based mechanism that uses symmetric cryptography.
<span class="grey">Niemi, et. al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Table of Contents
<a href="#section-1">1</a>. Introduction and Motivation . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a> Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.2">1.2</a> Conventions . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Specification of Digest AKA . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a> Algorithm Directive . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a> Creating a Challenge . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a> Client Authentication . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4">3.4</a> Synchronization Failure . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.5">3.5</a> Server Authentication . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Example Digest AKA Operation . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1">5.1</a> Authentication of Clients using Digest AKA . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2">5.2</a> Limited Use of Nonce Values . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.3">5.3</a> Multiple Authentication Schemes and Algorithms . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.4">5.4</a> Online Dictionary Attacks . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.5">5.5</a> Session Protection . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.6">5.6</a> Replay Protection . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.7">5.7</a> Improvements to AKA Security . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.1">6.1</a> Registration Template . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Informative References . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A">A</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Motivation</span>
The Hypertext Transfer Protocol (HTTP) Authentication Framework,
described in <a href="./rfc2617">RFC 2617</a> [<a href="#ref-2" title=""HTTP Authentication: Basic and Digest Access Authentication"">2</a>], includes two authentication schemes: Basic
and Digest. Both schemes employ a shared secret based mechanism for
access authentication. The Basic scheme is inherently insecure in
that it transmits user credentials in plain text. The Digest scheme
improves security by hiding user credentials with cryptographic
hashes, and additionally by providing limited message integrity.
The Authentication and Key Agreement (AKA) [<a href="#ref-6" title=""Security Architecture (Release 4)"">6</a>] mechanism performs
authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks. AKA is a challenge-
response based mechanism that uses symmetric cryptography. AKA is
typically run in a UMTS IM Services Identity Module (ISIM), which
resides on a smart card like device that also provides tamper
resistant storage of shared secrets.
<span class="grey">Niemi, et. al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
This document specifies a mapping of AKA parameters onto HTTP Digest
authentication. In essence, this mapping enables the usage of AKA as
a one-time password generation mechanism for Digest authentication.
As the Session Initiation Protocol (SIP) [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] Authentication Framework
closely follows the HTTP Authentication Framework, Digest AKA is
directly applicable to SIP as well as any other embodiment of HTTP
Digest.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> Terminology</span>
This chapter explains the terminology used in this document.
AKA
Authentication and Key Agreement.
AuC
Authentication Center. The network element in mobile networks
that can authorize users either in GSM or in UMTS networks.
AUTN
Authentication Token. A 128 bit value generated by the AuC, which
together with the RAND parameter authenticates the server to the
client.
AUTS
Authentication Token. A 112 bit value generated by the client
upon experiencing an SQN synchronization failure.
CK
Cipher Key. An AKA session key for encryption.
IK
Integrity Key. An AKA session key for integrity check.
ISIM
IP Multimedia Services Identity Module.
PIN
Personal Identification Number. Commonly assigned passcodes for
use with automatic cash machines, smart cards, etc.
RAND
Random Challenge. Generated by the AuC using the SQN.
RES
Authentication Response. Generated by the ISIM.
<span class="grey">Niemi, et. al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
SIM
Subscriber Identity Module. GSM counter part for ISIM.
SQN
Sequence Number. Both AuC and ISIM maintain the value of the SQN.
UMTS
Universal Mobile Telecommunications System.
XRES
Expected Authentication Response. In a successful authentication
this is equal to RES.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Conventions</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. AKA Mechanism Overview</span>
This chapter describes the AKA operation in detail:
1. A shared secret K is established beforehand between the ISIM and
the Authentication Center (AuC). The secret is stored in the
ISIM, which resides on a smart card like, tamper resistant device.
2. The AuC of the home network produces an authentication vector AV,
based on the shared secret K and a sequence number SQN. The
authentication vector contains a random challenge RAND, network
authentication token AUTN, expected authentication result XRES, a
session key for integrity check IK, and a session key for
encryption CK.
3. The authentication vector is downloaded to a server. Optionally,
the server can also download a batch of AVs, containing more than
one authentication vector.
4. The server creates an authentication request, which contains the
random challenge RAND, and the network authenticator token AUTN.
5. The authentication request is delivered to the client.
6. Using the shared secret K and the sequence number SQN, the client
verifies the AUTN with the ISIM. If the verification is
successful, the network has been authenticated. The client then
produces an authentication response RES, using the shared secret K
and the random challenge RAND.
<span class="grey">Niemi, et. al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
7. The authentication response, RES, is delivered to the server.
8. The server compares the authentication response RES with the
expected response, XRES. If the two match, the user has been
successfully authenticated, and the session keys, IK and CK, can
be used for protecting further communications between the client
and the server.
When verifying the AUTN, the client may detect that the sequence
numbers between the client and the server have fallen out of sync.
In this case, the client produces a synchronization parameter AUTS,
using the shared secret K and the client sequence number SQN. The
AUTS parameter is delivered to the network in the authentication
response, and the authentication can be tried again based on
authentication vectors generated with the synchronized sequence
number.
For a specification of the AKA mechanism and the generation of the
cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference
3GPP TS 33.102 [<a href="#ref-6" title=""Security Architecture (Release 4)"">6</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Specification of Digest AKA</span>
In general, the Digest AKA operation is identical to the Digest
operation in <a href="./rfc2617">RFC 2617</a> [<a href="#ref-2" title=""HTTP Authentication: Basic and Digest Access Authentication"">2</a>]. This chapter specifies the parts in which
Digest AKA extends the Digest operation. The notation used in the
Augmented BNF definitions for the new and modified syntax elements in
this section is as used in SIP [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>], and any elements not defined in
this section are as defined in SIP and the documents to which it
refers.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Algorithm Directive</span>
In order to direct the client into using AKA for authentication
instead of the standard password system, the <a href="./rfc2617">RFC 2617</a> defined
algorithm directive is overloaded in Digest AKA:
algorithm = "algorithm" EQUAL ( aka-namespace
/ algorithm-value )
aka-namespace = aka-version "-" algorithm-value
aka-version = "AKAv" 1*DIGIT
algorithm-value = ( "MD5" / "MD5-sess" / token )
algorithm
A string indicating the algorithm used in producing the digest and
the checksum. If the directive is not understood, the nonce
SHOULD be ignored, and another challenge (if one is present)
should be used instead. The default aka-version is "AKAv1".
<span class="grey">Niemi, et. al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Further AKA versions can be specified, with version numbers
assigned by IANA [<a href="#ref-7" title=""Assigned Numbers"">7</a>]. When the algorithm directive is not
present, it is assumed to be "MD5". This indicates, that AKA is
not used to produce the Digest password.
Example:
algorithm=AKAv1-MD5
If the entropy of the used RES value is limited (e.g., only 32
bits), reuse of the same RES value in authenticating subsequent
requests and responses is NOT RECOMMENDED. Such a RES value
SHOULD only be used as a one-time password, and algorithms such as
"MD5-sess", which limit the amount of material hashed with a
single key, by producing a session key for authentication, SHOULD
NOT be used.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Creating a Challenge</span>
In order to deliver the AKA authentication challenge to the client in
Digest AKA, the nonce directive defined in <a href="./rfc2617">RFC 2617</a> is extended:
nonce = "nonce" EQUAL ( aka-nonce
/ nonce-value )
aka-nonce = LDQUOT aka-nonce-value RDQUOT
aka-nonce-value = <base64 encoding of RAND, AUTN, and
server specific data>
nonce
A parameter, which is populated with the Base64 [<a href="#ref-4" title=""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"">4</a>] encoding of
the concatenation of the AKA authentication challenge RAND, the
AKA AUTN token, and optionally some server specific data, as in
Figure 1.
<span class="grey">Niemi, et. al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Example:
nonce="MzQ0a2xrbGtmbGtsZm9wb2tsc2tqaHJzZXNy9uQyMzMzMzQK="
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| RAND |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AUTN |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Data...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generating the nonce value.
If the server receives a client authentication containing the "auts"
parameter defined in <a href="#section-3.4">Section 3.4</a>, that includes a valid AKA AUTS
parameter, the server MUST use it to generate a new challenge to the
client. Note that when the AUTS is present, the included "response"
parameter is calculated using an empty password (password of ""),
instead of a RES.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> Client Authentication</span>
When a client receives a Digest AKA authentication challenge, it
extracts the RAND and AUTN from the "nonce" parameter, and assesses
the AUTN token provided by the server. If the client successfully
authenticates the server with the AUTN, and determines that the SQN
used in generating the challenge is within expected range, the AKA
algorithms are run with the RAND challenge and shared secret K.
The resulting AKA RES parameter is treated as a "password" when
calculating the response directive of <a href="./rfc2617">RFC 2617</a>.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a> Synchronization Failure</span>
For indicating an AKA sequence number synchronization failure, and to
re-synchronize the SQN in the AuC using the AUTS token, a new
directive is defined for the "digest-response" of the "Authorization"
request header defined in <a href="./rfc2617">RFC 2617</a>:
<span class="grey">Niemi, et. al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
auts = "auts" EQUAL auts-param
auts-param = LDQUOT auts-value RDQUOT
auts-value = <base64 encoding of AUTS>
auts
A string carrying a base64 encoded AKA AUTS parameter. This
directive is used to re-synchronize the server side SQN. If the
directive is present, the client doesn't use any password when
calculating its credentials. Instead, the client MUST calculate
its credentials using an empty password (password of "").
Example:
auts="CjkyMzRfOiwg5CfkJ2UK="
Upon receiving the "auts" parameter, the server will check the
validity of the parameter value using the shared secret K. A valid
AUTS parameter is used to re-synchronize the SQN in the AuC. The
synchronized SQN is then used to generate a fresh authentication
vector AV, with which the client is then re-challenged.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a> Server Authentication</span>
Even though AKA provides inherent mutual authentication with the AKA
AUTN token, mutual authentication mechanisms provided by Digest may
still be useful in order to provide message integrity.
In Digest AKA, the server uses the AKA XRES parameter as "password"
when calculating the "response-auth" of the "Authentication-Info"
header defined in <a href="./rfc2617">RFC 2617</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Example Digest AKA Operation</span>
Figure 2 below describes a message flow describing a Digest AKA
process of authenticating a SIP request, namely the SIP REGISTER
request.
<span class="grey">Niemi, et. al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Client Server
| 1) REGISTER |
|------------------------------------------------------>|
| |
| +-----------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +-----------------------------+
| |
| 2) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (RAND, AUTN delivered) |
|<------------------------------------------------------|
| |
+------------------------------------+ |
| Client runs AKA algorithms on ISIM,| |
| verifies AUTN, derives RES | |
| and session keys. | |
+------------------------------------+ |
| |
| 3) REGISTER |
| Authorization: Digest (RES is used) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server checks the given RES, |
| | and finds it correct. |
| +------------------------------+
| |
| 4) 200 OK |
| Authentication-Info: (XRES is used) |
|<------------------------------------------------------|
| |
Figure 2: Message flow representing a successful authentication.
1) Initial request
REGISTER sip:home.mobile.biz SIP/2.0
<span class="grey">Niemi, et. al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
2) Response containing a challenge
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="RoamingUsers@mobile.biz",
nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
qop="auth,auth-int",
opaque="5ccc069c403ebaf9f0171e9517f40e41",
algorithm=AKAv1-MD5
3) Request containing credentials
REGISTER sip:home.mobile.biz SIP/2.0
Authorization: Digest
username="jon.dough@mobile.biz",
realm="RoamingUsers@mobile.biz",
nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
uri="sip:home.mobile.biz",
qop=auth-int,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
4) Successful response
SIP/2.0 200 OK
Authentication-Info:
qop=auth-int,
rspauth="6629fae49393a05397450978507c4ef1",
cnonce="0a4f113b",
nc=00000001
<span class="grey">Niemi, et. al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Figure 3 below describes a message flow describing a Digest AKA
authentication process, in which there is a synchronization failure.
Client Server
| 1) REGISTER |
|------------------------------------------------------>|
| |
| +-----------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +-----------------------------+
| |
| 2) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (RAND, AUTN delivered) |
|<------------------------------------------------------|
| |
+------------------------------------+ |
| Client runs AKA algorithms on ISIM,| |
| verifies the AUTN, but discovers | |
| that it contains an invalid | |
| sequence number. The client then | |
| generates an AUTS token. | |
+------------------------------------+ |
| |
| 3) REGISTER |
| Authorization: Digest (AUTS is delivered) |
|------------------------------------------------------>|
| |
| +-----------------------+
| | Server performs |
| | re-synchronization |
| | using AUTS and RAND. |
| +-----------------------+
| |
| 4) 401 Unauthorized |
| WWW-Authenticate: Digest |
| (re-synchronized RAND, |
| AUTN delivered) |
|<------------------------------------------------------|
| |
Figure 3: Message flow representing an authentication synchronization
failure.
<span class="grey">Niemi, et. al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
1) Initial request
REGISTER sip:home.mobile.biz SIP/2.0
2) Response containing a challenge
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="RoamingUsers@mobile.biz",
qop="auth",
nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
opaque="5ccc069c403ebaf9f0171e9517f40e41",
algorithm=AKAv1-MD5
3) Request containing credentials
REGISTER sip:home.mobile.biz SIP/2.0
Authorization: Digest
username="jon.dough@mobile.biz",
realm="RoamingUsers@mobile.biz",
nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==",
uri="sip:home.mobile.biz",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="4429ffe49393c02397450934607c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41",
auts="5PYxMuX2NOT2NeQ="
4) Response containing a new challenge
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest
realm="RoamingUsers@mobile.biz",
qop="auth,auth-int",
nonce="9uQzNPbk9jM05Pbl5Pbl5DIz9uTl9uTl9jM0NTHk9uXk==",
opaque="dcd98b7102dd2f0e8b11d0f600bfb0c093",
algorithm=AKAv1-MD5
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
In general, Digest AKA is vulnerable to the same security threats as
HTTP authentication [<a href="#ref-2" title=""HTTP Authentication: Basic and Digest Access Authentication"">2</a>]. This chapter discusses the relevant
exceptions.
<span class="grey">Niemi, et. al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a> Authentication of Clients using Digest AKA</span>
AKA is typically -- though this isn't a theoretical limitation -- run
on an ISIM application that usually resides in a tamper resistant
smart card. Interfaces to the ISIM exist, which enable the host
device to request authentication to be performed on the card.
However, these interfaces do not allow access to the long-term secret
outside the ISIM, and the authentication can only be performed if the
device accessing the ISIM has knowledge of a PIN code, shared between
the user and the ISIM. Such PIN codes are typically obtained from
user input, and are usually required when the device is powered on.
The use of tamper resistant cards with secure interfaces implies that
Digest AKA is typically more secure than regular Digest
implementations, as neither possession of the host device nor Trojan
Horses in the software give access to the long term secret. Where a
PIN scheme is used, the user is also authenticated when the device is
powered on. However, there may be a difference in the resulting
security of Digest AKA, compared to traditional Digest
implementations, depending of course on whether those implementations
cache/store passwords that are received from the user.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a> Limited Use of Nonce Values</span>
The Digest scheme uses server-specified nonce values to seed the
generation of the request-digest value. The server is free to
construct the nonce in such a way, that it may only be used from a
particular client, for a particular resource, for a limited period of
time or number of uses, or any other restrictions. Doing so
strengthens the protection provided against, for example, replay
attacks.
Digest AKA limits the applicability of a nonce value to a particular
ISIM. Typically, the ISIM is accessible only to one client device at
a time. However, the nonce values are strong and secure even though
limited to a particular ISIM. Additionally, this requires that the
server is provided with the client identity before an authentication
challenge can be generated. If a client identity is not available,
an additional round trip is needed to acquire it. Such a case is
analogous to an AKA synchronization failure.
A server may allow each nonce value to be used only once by sending a
next-nonce directive in the Authentication-Info header field of every
response. However, this may cause a synchronization failure, and
consequently some additional round trips in AKA, if the same SQN
space is also used for other access schemes at the same time.
<span class="grey">Niemi, et. al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a> Multiple Authentication Schemes and Algorithms</span>
In HTTP authentication, a user agent MUST choose the strongest
authentication scheme it understands and request credentials from the
user, based upon that challenge.
In general, using passwords generated by Digest AKA with other HTTP
authentication schemes is not recommended even though the realm
values or protection domains would coincide. In these cases, a
password should be requested from the end-user instead. Digest AKA
passwords MUST NOT be re-used with such HTTP authentication schemes,
which send the password in clear. In particular, AKA passwords MUST
NOT be re-used with HTTP Basic.
The same principle must be applied within a scheme if several
algorithms are supported. A client receiving an HTTP Digest
challenge with several available algorithms MUST choose the strongest
algorithm it understands. For example, Digest with "AKAv1-MD5" would
be stronger than Digest with "MD5".
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a> Online Dictionary Attacks</span>
Since user-selected passwords are typically quite simple, it has been
proposed that servers should not accept passwords for HTTP Digest,
which are in the dictionary [<a href="#ref-2" title=""HTTP Authentication: Basic and Digest Access Authentication"">2</a>]. This potential threat does not
exist in HTTP Digest AKA because the algorithm will use ISIM
originated passwords. However, the end-user must still be careful
with PIN codes. Even though HTTP Digest AKA password requests are
never displayed to the end-user, she will be authenticated to the
ISIM via a PIN code. Commonly known initial PIN codes are typically
installed to the ISIM during manufacturing and if the end-users do
not change them, there is a danger that an unauthorized user may be
able to use the device. Naturally this requires that the
unauthorized user has access to the physical device, and that the
end-user has not changed the initial PIN code. For this reason,
end-users are strongly encouraged to change their PIN codes when they
receive an ISIM.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a> Session Protection</span>
Digest AKA is able to generate additional session keys for integrity
(IK) and confidentiality (CK) protection. Even though this document
does not specify the use of these additional keys, they may be used
for creating additional security within HTTP authentication or some
other security mechanism.
<span class="grey">Niemi, et. al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a> Replay Protection</span>
AKA allows sequence numbers to be tracked for each authentication,
with the SQN parameter. This allows authentications to be replay
protected even if the RAND parameter happened to be the same for two
authentication requests. More importantly, this offers additional
protection for the case where an attacker replays an old
authentication request sent by the network. The client will be able
to detect that the request is old, and refuse authentication. This
proves liveliness of the authentication request even in the case
where a MitM attacker tries to trick the client into providing an
authentication response, and then replaces parts of the message with
something else. In other words, a client challenged by Digest AKA is
not vulnerable for chosen plain text attacks. Finally, frequent
sequence number errors would reveal an attack where the tamper
resistant card has been cloned and is being used in multiple devices.
The downside of sequence number tracking is that servers must hold
more information for each user than just their long-term secret,
namely the current SQN value. However, this information is typically
not stored in the SIP nodes, but in dedicated authentication servers
instead.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a> Improvements to AKA Security</span>
Even though AKA is perceived as a secure mechanism, Digest AKA is
able to improve it. More specifically, the AKA parameters carried
between the client and the server during authentication may be
protected along with other parts of the message by using Digest AKA.
This is not possible with plain AKA.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document specifies an aka-version namespace in <a href="#section-3.1">Section 3.1</a> which
requires a central coordinating body. The body responsible for this
coordination is the Internet Assigned Numbers Authority (IANA).
The default aka-version defined in this document is "AKAv1".
Following the policies outlined in [<a href="#ref-5" title="">5</a>], versions above 1 are
allocated as Expert Review.
Registrations with the IANA MUST include the version number being
registered, including the "AKAv" prefix. For example, a registration
for "AKAv2" would potentially be a valid one, whereas a registration
for "FOOv2" or "2" would not be valid. Further, the registration
MUST include contact information for the party responsible for the
registration.
<span class="grey">Niemi, et. al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
As this document defines the default aka-version, the initial IANA
registration for aka-version values will contain an entry for
"AKAv1".
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a> Registration Template</span>
To: ietf-digest-aka@iana.org
Subject: Registration of a new AKA version
Version identifier:
(Must contain a valid aka-version value,
as described in <a href="#section-3.1">section 3.1</a>.)
Person & email address to contact for further information:
(Must contain contact information for the
person(s) responsible for the registration.)
Normative References
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", <a href="./rfc2617">RFC 2617</a>, June 1999.
[<a id="ref-3">3</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
[<a id="ref-4">4</a>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
<a href="./rfc2045">RFC 2045</a>, November 1996.
Informative References
[<a id="ref-5">5</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
[<a id="ref-6">6</a>] 3rd Generation Partnership Project, "Security Architecture
(Release 4)", TS 33.102, December 2001.
[<a id="ref-7">7</a>] <a href="http://www.iana.org">http://www.iana.org</a>, "Assigned Numbers".
<span class="grey">Niemi, et. al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgements</span>
The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete
McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney,
Allison Mankin and Greg Rose.
Authors' Addresses
Aki Niemi
Nokia
P.O. Box 301
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Jari Arkko
Ericsson
Hirsalantie 1
Jorvas, FIN 02420
Finland
Phone: +358 40 5079256
EMail: jari.arkko@ericsson.com
Vesa Torvinen
Ericsson
Joukahaisenkatu 1
Turku, FIN 20520
Finland
Phone: +358 40 7230822
EMail: vesa.torvinen@ericsson.fi
<span class="grey">Niemi, et. al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3310">RFC 3310</a> HTTP Digest Authentication Using AKA September 2002</span>
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Niemi, et. al. Informational [Page 18]
</pre>
|
