File: rfc2847.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1235 lines) | stat: -rw-r--r-- 50,045 bytes parent folder | download | duplicates (5)
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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235






Network Working Group                                          M. Eisler
Request for Comments: 2847                                       Zambeel
Category: Standards Track                                      June 2000


     LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memorandum describes a method whereby one can use GSS-API
   [RFC2078] to supply a secure channel between a client and server,
   authenticating the client with a password, and a server with a public
   key certificate.  As such, it is analogous to the common low
   infrastructure usage of the Transport Layer Security (TLS) protocol
   [RFC2246].

   The method leverages the existing Simple Public Key Mechanism (SPKM)
   [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY)
   layered above SPKM.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  LIPKEY's Requirements of SPKM  . . . . . . . . . . . . . . . . 4
   2.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
   2.2.  Name Type  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.3.  Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.3.1.  MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
   2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
   2.4.  Context Establishment Tokens . . . . . . . . . . . . . . . . 8
   2.4.1.  REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
   2.4.1.1.  algId and req-integrity  . . . . . . . . . . . . . . . . 8
   2.4.1.2.  Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
   2.4.1.2.1.  Options  . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.2.  Conf-Algs  . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.3.  Intg-Algs  . . . . . . . . . . . . . . . . . . . . . . 9



Eisler                      Standards Track                     [Page 1]

RFC 2847                         LIPKEY                        June 2000


   2.4.2.  REP-TI-TOKEN Content Requirements  . . . . . . . . . . . . 9
   2.4.2.1.  algId  . . . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.2.2.  rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
   2.5.  Quality of Protection (QOP)  . . . . . . . . . . . . . . . .10
   3.  How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . .  11
   3.1.  Tokens . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.  Initiator  . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  11
   3.2.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  11
   3.2.3.  GSS_Init_sec_context . . . . . . . . . . . . . . . . . .  12
   3.2.3.1.  LIPKEY Caller Specified anon_req_flag as TRUE  . . . .  12
   3.2.3.2.  LIPKEY Caller Specified anon_req_flag as FALSE . . . .  13
   3.2.4.  Other operations . . . . . . . . . . . . . . . . . . . .  14
   3.3.  Target . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   3.3.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  14
   3.3.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  14
   3.3.3.  GSS_Accept_sec_context . . . . . . . . . . . . . . . . .  15
   4.  LIPKEY Description . . . . . . . . . . . . . . . . . . . . .  15
   4.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . .  15
   4.2.  Name Types . . . . . . . . . . . . . . . . . . . . . . . .  15
   4.3.  Token Formats  . . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.  Context Tokens . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.1.  Context Tokens Prior to SPKM-3 Context Establishment .  16
   4.3.1.2.  Post-SPKM-3 Context Establishment Tokens . . . . . . .  16
   4.3.1.2.1.  From LIPKEY Initiator  . . . . . . . . . . . . . . .  17
   4.3.1.2.2.  From LIPKEY Target . . . . . . . . . . . . . . . . .  17
   4.3.2.  Tokens from GSS_GetMIC and GSS_Wrap  . . . . . . . . . .  17
   4.4.  Quality of Protection  . . . . . . . . . . . . . . . . . .  18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   5.1.  Password Management  . . . . . . . . . . . . . . . . . . .  18
   5.2.  Certification Authorities  . . . . . . . . . . . . . . . .  18
   5.3.  HMAC-MD5 and MD5 Weaknesses  . . . . . . . . . . . . . . .  18
   5.4.  Security of cast5CBC . . . . . . . . . . . . . . . . . . .  18
   References . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  21
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   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].

   This memorandum describes a new security mechanism under the GSS-API
   called the Low Infrastructure Public Key Mechanism (LIPKEY).  GSS-API
   provides a way for an application protocol to implement
   authentication, integrity, and privacy. TLS is another way. While TLS



Eisler                      Standards Track                     [Page 2]

RFC 2847                         LIPKEY                        June 2000


   is in many ways simpler for an application to incorporate than GSS-
   API, there are situations where GSS-API might be more suitable.
   Certainly this is the case with application protocols that run over
   connectionless protocols. It is also the case with application
   protocols such as ONC RPC [RFC1831] [RFC2203], which have their own
   security architecture, and so do not easily mesh with a protocol like
   TLS that is implemented as a layer that encapsulates the upper layer
   application protocol. GSS-API allows the application protocol to
   encapsulate as much of the application protocol as necessary.

   Despite the flexibility of GSS-API, it compares unfavorably with TLS
   with respect to the perception of the amount of infrastructure
   required to deploy it. The better known GSS-API mechanisms, Kerberos
   V5 [RFC1964] and SPKM require a great deal of infrastructure to set
   up. Compare this to the typical TLS deployment scenario, which
   consists of a client with no public key certificate accessing a
   server with a public key certificate.  The client:

   *    obtains the server's certificate,

   *    verifies that it was signed by a trusted Certification Authority
        (CA),

   *    generates a random session symmetric key,

   *    encrypts the session key with the server's public key, and

   *    sends the encrypted session key to the server.

   At this point, the client and server have a secure channel.  The
   client can then provide a user name and password to the server to
   authenticate the client. For example, when TLS is being used with the
   http protocol, once there is a secure channel, the http server will
   present the client with an html page that prompts for a user name and
   password. This information is then encrypted with the session key and
   sent to the server. The server then authenticates the client.

   Note that the client is not required to have a certificate for itself
   to identify and authenticate it to the server. In addition to a TLS
   implementation, the required security infrastructure includes a
   public key certificate and password database on the server, and a
   list of trusted CAs and their public keys on the client. Most
   operating systems that the http server would run on already have a
   native password database, so the net additional infrastructure is a
   server certificate and CA list. Hence the term "low infrastructure
   security model" to identify this typical TLS deployment scenario.





Eisler                      Standards Track                     [Page 3]

RFC 2847                         LIPKEY                        June 2000


   By using unilateral authentication, and using a mechanism resembling
   the SPKM-1 mechanism type, SPKM can offer many aspects of the
   previously described low infrastructure security model. An
   application that uses GSS-API is certainly free to use GSS-API's
   GSS_Wrap() routine to encrypt a user name and password and send them
   to the server, for it to decrypt and verify.

   Applications often have application protocols associated with them,
   and there might not be any provision in the protocol to specify a
   password.  Layering a thin GSS-API mechanism over a mechanism
   resembling SPKM-1 can mitigate this problem. This can be a useful
   approach to avoid modifying applications that have already bound to
   GSS-API, assuming the applications are not statically bound to
   specific GSS-API mechanisms.  The remainder of this memorandum
   defines the thin mechanism: the Low Infrastructure Public Key
   Mechanism (LIPKEY).

2.  LIPKEY's Requirements of SPKM

   SPKM-1 with unilateral authentication is close to the desired low
   infrastructure model described earlier. This section describes some
   additional changes to how SPKM-1 operates in order to realize the low
   infrastructure model.  These changes include some minor changes in
   semantics.  While it would be possible to implement these semantic
   changes within an SPKM-1 implementation (including using the same
   mechanism type Object Identifier (OID) as SPKM-1), the set of changes
   stretch the interpretation of RFC 2025 to the point where
   compatibility would be in danger. A new mechanism type, called SPKM-
   3, is warranted. LIPKEY requires that the SPKM implementation support
   SPKM-3.  SPKM-3 is equivalent to SPKM-1, except as described in the
   remainder of this section.

2.1.  Mechanism Type

   SPKM-3 has a different mechanism type OID from SPKM-1.

   spkm-3 OBJECT IDENTIFIER ::=
      {iso(1)identified-organization(3)dod(6)internet(1)security(5)
      mechanisms(5)spkm(1)spkm-3(3)}

2.2.  Name Type

   RFC 2025 defines no required name types of SPKM. LIPKEY requires that
   the SPKM-3 implementation support all the mechanism independent name
   types in RFC 2078.






Eisler                      Standards Track                     [Page 4]

RFC 2847                         LIPKEY                        June 2000


2.3.  Algorithms

2.3.1.  MANDATORY Algorithms

   RFC 2025 defines various algorithms for integrity, confidentiality,
   key establishment, and subkey derivation.  Except for
   md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG),
   Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG)
   algorithms listed in RFC 2025 continue to be REQUIRED.

   SPKM is designed to be extensible with regard to new algorithms. In
   order for LIPKEY to work correctly and securely, the following
   algorithms MUST be implemented in SPKM-3:

   *    Integrity algorithms (I-ALG)

      NULL-MAC
           Because the initiator may not have a certificate for itself,
           nor for the target, it is not possible for it to calculate an
           Integrity value in the initiator's REQ-TOKEN that is sent to
           the target. So we define, in ASN.1 [CCITT] syntax, a null I-
           ALG that returns a zero length bit string regardless of the
           input passed to it:

      NULL-MAC OBJECT IDENTIFIER ::=
         {iso(1)identified-organization(3)dod(6)internet(1)security(5)
         integrity(3)NULL-MAC(3)}

      id-dsa-with-sha1
           This is the signature algorithm as defined in Section 7.2.2
           of [RFC2459].  As noted in RFC 2459, the ASN.1 OID used to
           identify this signature algorithm is:

              id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
                      iso(1) member-body(2) us(840) x9-57(10040)
                              x9cm(4) 3
              }

           Note that there is a work-in-progress [PKIX] to obsolete RFC
           2459. However that work-in-progress does not change the
           definition of id-dsa-with-sha1.

      HMAC-MD5
           A consequence of the SPKM-3 initiator not having a
           certificate is that it cannot use a digital signature
           algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or
           sha1WithRSAEncryption once the context is established.
           Instead, a message authentication code (MAC) algorithm is



Eisler                      Standards Track                     [Page 5]

RFC 2847                         LIPKEY                        June 2000


           required. DES-MAC is specified as recommended in [RFC2025].
           Since the security of 56 bit DES has been shown to be
           inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3
           MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:

              HMAC-MD5 OBJECT IDENTIFIER ::= {
                      iso(1) org(3) dod(6) internet(1) security(5)
                              mechanisms(5) ipsec(8) isakmpOakley(1)
                              1
              }

           The reference for the algorithm OID of HMAC-MD5 is [IANA].
           The reference for the HMAC-MD5 algorithm is [RFC2104].

           The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC
           because SHA-1 is about half the speed of MD5 [Young].  A MAC
           based on an encryption algorithm like cast5CBC, DES EDE3, or
           RC4 is not mandatory because MD5 is 31 percent faster than
           the fastest of the three encryption algorithms [Young].

   *    Confidentiality algorithm (C-ALG).

        RFC 2025 does not have a MANDATORY confidentiality algorithm,
        and instead has RECOMMENDED a 56 bit DES algorithm. Since the
        LIPKEY initiator needs to send a password to the target, and
        since 56 bit DES has been demonstrated as inadequate [EFF],
        LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this
        algorithm:

           cast5CBC OBJECT IDENTIFIER ::= {
                   iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
                           algorithms(66) 10
           }

           Parameters ::= SEQUENCE {
                   iv OCTET STRING DEFAULT 0, -- Initialization vector
                   keyLength INTEGER          -- Key length, in bits
           }

        The reference for the OID and description of the cast5CBC
        algorithm is [RFC2144]. The keyLength in the Parameters MUST be
        set to 128 bits.

        A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C-
        ALG because it is much slower than cast5CBC. One set of
        measurements [Young] on a Pentium Pro 200 megahertz processor
        using the SSLeay code, showed that DES EDE3 performed as high as
        1,646,210 bytes per second, using 1024 byte blocks. The same



Eisler                      Standards Track                     [Page 6]

RFC 2847                         LIPKEY                        June 2000


        test bed yielded performance of 7,147,760 bytes per second for
        cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS
        sessions negotiate the RC4 cipher. Given that LIPKEY is targeted
        at environments similar to that where TLS is deployed, selecting
        a cipher that is over 13 times slower (and over 13 times more
        CPU intensive) than RC4 would severely impede the usefulness of
        LIPKEY.  For performance reasons, RC4 would be the preferred
        mandatory algorithm for SPKM-3. Due to intellectual property
        considerations with RC4 [Schneier], the combination of
        cast5CBC's reasonable performance, and its royalty-free
        licensing terms [RFC2144] make cast5CBC the optimal choice among
        DES EDE3, RC4, and cast5CBC.

   *    Key Establishment Algorithm (K-ALG)

        RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional
        algorithm.  As will be described later, the RSAEncryption key
        establishment algorithm is of no use for a low infrastructure
        security mechanism as defined by this memorandum. Hence, in
        SPKM-3, dhKeyAgreement is a REQUIRED key establishment
        algorithm:

           dhKeyAgreement OBJECT IDENTIFIER ::= {
                   iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
                   pkcs-3(3) 1
           }

   *    One-Way Function for Subkey Derivation Algorithm (O-ALG)

        RFC 2025 lists MD5 as a mandatory algorithm.  Since MD5 has been
        found to have weaknesses when used as a hash [Dobbertin], id-
        sha1 is a MANDATORY O-ALG in SPKM-3:

           id-sha1 OBJECT IDENTIFIER ::= {
                   iso(1) identified-organization(3) oiw(14)
                   secsig(3) algorithms(2) 26
           }

        The reference for the algorithm OID of id-sha1 is [RFC2437].
        The reference for SHA-1 algorithm corresponding to id-sha1 is
        [FIPS].

2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG)

   md5WithRSAEncryption
        The md5WithRSAEncryption integrity algorithm is listed in
        [RFC2025] as mandatory.  Due to intellectual property
        considerations [RSA-IP], SPKM-3 implementations cannot be



Eisler                      Standards Track                     [Page 7]

RFC 2847                         LIPKEY                        June 2000


        required to implement it. However, given the proliferation of
        certificates using RSA public keys, md5WithRSAEncryption is
        strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to
        leverage existing public key infrastructure will be limited.

   sha1WithRSAEncryption
        For reasons similar to that for md5WithRSAEncryption,
        sha1WithRSAEncryption is a RECOMMENDED algorithm. The
        sha1WithRSAEncryption algorithm is listed in addition to
        md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm
        [Dobbertin]. The OID for sha1WithRSAEncryption is:

           sha1WithRSAEncryption  OBJECT IDENTIFIER ::= {
                   iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
                   pkcs-1(1) 5
           }

        The reference for the algorithm OID and description of
        sha1WithRSAEncryption is [RFC2437].

2.4.  Context Establishment Tokens

   RFC 2025 sets up a context with an initiator first token (REQ-TOKEN),
   a target reply (REP-TI-TOKEN), and finally an initiator second token
   (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses
   SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used.
   LIPKEY has certain requirements on the contents of the REQ-TOKEN and
   REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different
   from RFC 2025's SPKM-1 tokens.

2.4.1.  REQ-TOKEN Content Requirements

2.4.1.1.  algId and req-integrity

   If the SPKM-3 initiator cannot calculate a req-integrity field due to
   the lack of a target certificate, it MUST use the NULL-MAC I-ALG
   described earlier in this memorandum. This will produce a zero length
   bit string in the Integrity field.

2.4.1.2.  Req-contents

   Because RFC 2025 requires that the RSAEncryption K-ALG be present,
   SPKM-1 must be able to map the target (targ-name) to its public key
   certificate, and thus SPKM can use the RSAEncryption algorithm to
   fill in the key-estb-req field.  Because LIPKEY assumes a low
   infrastructure deployment, SPKM-3 MUST be prepared to be unable to
   map the targ-name field of the Req-contents field.  This is a
   contradiction which is resolved by requiring SPKM-3 to support the



Eisler                      Standards Track                     [Page 8]

RFC 2847                         LIPKEY                        June 2000


   dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries
   to map the target to a certificate, and succeeds, it is free to use
   the RSAEncryption K-ALG algorithm. It is also free to use an algID
   other than NULL-MAC in the REQ-TOKEN type.

2.4.1.2.1.  Options

   SPKM-3 implementations MUST set the target-certif-data-required bit
   to 1 if the only K-ALG in the key-estb-set field of Req-contents is
   dhKeyAgreement. This would normally occur if the SPKM-3
   implementation cannot resolve the target name to a certificate.

2.4.1.2.2.  Conf-Algs

   If the SPKM-3 implementation supports an algorithm weaker than
   cast5CBC, cast5CBC MUST be listed before the weaker algorithm to
   encourage the target to negotiate the stronger algorithm.

2.4.1.2.3.  Intg-Algs

   Because the initiator will be anonymous (at the SPKM-3 level) and
   will not have a certificate for itself, the initiator cannot use an
   integrity algorithm that supports non-repudiation; it must use a MAC
   algorithm. If the SPKM-3 implementation supports an algorithm weaker
   than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to
   encourage the target to negotiate the stronger algorithm.

2.4.2.  REP-TI-TOKEN Content Requirements

   With the previously described requirements on REQ-TOKEN, the contents
   of SPKM-3's REP-TI-TOKEN can for the most part be derived from the
   specification in RFC 2025. The exceptions are the algId and rep-ti-
   integ fields.

2.4.2.1.  algId

   The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a
   signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or
   sha1WithRSAEncryption.

2.4.2.2.  rep-ti-integ

   If the req-token has an algId of NULL-MAC, then the target MUST
   compute the rep-ti-integ on the concatenation of the req-contents and
   rep-ti-contents.






Eisler                      Standards Track                     [Page 9]

RFC 2847                         LIPKEY                        June 2000


2.5.  Quality of Protection (QOP)

   The SPKM-3 initiator and target negotiate the set of algorithms they
   mutually support, using the procedure defined in Section 5.2 of RFC
   2025. If a QOP of zero is specified, then the initiator and target
   will use the first C-ALG (privacy), and I-ALG (integrity) algorithms
   negotiated.

   SPKM breaks the QOP into several fields, as reproduced here from
   Section 5.2 of RFC 2025:

       Confidentiality                    Integrity
       31 (MSB)                        16 15                 (LSB) 0
      -------------------------------|-------------------------------
      | TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
      -------------------------------|-------------------------------

   The MA subfields enumerate mechanism-defined algorithms. Since this
   memorandum introduces a new mechanism, SPKM-3, within the SPKM
   family, it is appropriate to add algorithms to the MA subfields of
   the respective Confidentiality and Integrity fields.

   The complete set of Confidentiality MA algorithms is thus:

      0001 (1) = DES-CBC
      0010 (2) = cast5CBC

   Where "0001" and "0010" are in base 2.  An SPKM peer that negotiates
   a confidentiality MA algorithm value of "0010" MUST use a 128 bit
   key, i.e. set the keyLength values in the cast5CBC Parameters to 128
   bits.

   The complete set of Integrity MA algorithms is thus:

      0001 (1) = md5WithRSAEncryption
      0010 (2) = DES-MAC
      0011 (3) = id-dsa-with-sha1
      0100 (4) = HMAC-MD5
      0101 (5) = sha1WithRSAEncryption

   Where "0001" through "0101" are in base 2.

   Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and
   sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does
   not impair SPKM-1 and SPKM-2 backward compatibility because, as noted
   previously, SPKM negotiates algorithms. An older SPKM-1 or SPKM-2
   that does not recognize MA values for cast5CBC, id-dsa-with-sha1,
   HMAC-MD5, or sha1WithRSAEncryption will not select them.



Eisler                      Standards Track                    [Page 10]

RFC 2847                         LIPKEY                        June 2000


3.  How LIPKEY Uses SPKM

3.1.  Tokens

   LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism
   that the application uses is LIPKEY, LIPKEY will wrap some of the
   SPKM-3 tokens with LIPKEY prefixes. The exact definition of the
   tokens is described later in this memorandum.

3.2.  Initiator

3.2.1.  GSS_Import_name

   The initiator uses GSS_Import_name to import the target's name,
   typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE
   name type.  Ultimately, the output of GSS_Import_name will apply to
   an SPKM-3 mechanism type because a LIPKEY target is an SPKM-3 target.

3.2.2.  GSS_Acquire_cred

   The initiator calls GSS_Acquire_cred. The credentials that are
   acquired are LIPKEY credentials, a user name and password. How the
   user name and password is acquired is dependent upon the operating
   environment. A application that invokes GSS_Acquire_cred() while the
   application's user has a graphical user interface running might
   trigger the appearance of a pop up window that prompts for the
   information. A application embedded into the operating system, such
   as an NFS [Sandberg] client implemented as a native file system might
   broadcast a message to the user's terminals telling him to invoke a
   command that prompts for the information.

   Because the credentials will not be used until GSS_Init_sec_context
   is called, the LIPKEY implementation will need to safeguard the
   credentials. If this is a problem, the implementation may instead
   defer actual acquisition of the user name and password until
   GSS_init_sec_context is ready to send the user name and password to
   the target. In that event, the output_cred_handle argument of
   GSS_Acquire_cred would simply be a reference that mapped to the
   principal corresponding to the desired_name argument. A subsequent
   GSS_Init_sec_context call would consider the mapping of
   claimant_cred_handle to principal when it acquires the user name and
   password. For example, the aforementioned pop up window might fill in
   the user name portion of the dialog with a default value that maps to
   the principal referred to in claimant_cred_handle.







Eisler                      Standards Track                    [Page 11]

RFC 2847                         LIPKEY                        June 2000


3.2.3.  GSS_Init_sec_context

   When a program invokes GSS_Init_sec_context on the LIPKEY mechanism
   type, if the context handle is NULL, the LIPKEY mechanism will in
   turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented
   according to the requirements described previously. This call to
   SPKM-3 MUST have the following attributes:

   *    claimant_cred_handle is NULL

   *    mutual_req_flag is FALSE

   *    anon_req_flag is TRUE

   *    input_token is NULL

   *    mech_type is the OID of the SPKM-3 mechanism

   Keep in mind the above attributes are in the GSS_Init_sec_context
   call from the LIPKEY mechanism down to the SPKM-3 mechanism. There
   are no special restrictions placed on the application invoking
   LIPKEY's GSS_Init_sec_context routine.  All other arguments are
   derived from the LIPKEY GSS_Init_sec_context arguments.

   The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3
   context handle. The remainder of the description of the LIPKEY
   GSS_Init_sec_context call depends on whether the caller of the LIPKEY
   GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE.

3.2.3.1.  LIPKEY Caller Specified anon_req_flag as TRUE

   If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to
   TRUE, it MUST return to the LIPKEY caller all the outputs from the
   SPKM-3 GSS_Init_sec_context call, including the
   output_context_handle, output_token, and mech_type. In this way,
   LIPKEY now "gets out of the way" of GSS-API processing between the
   application and SPKM-3, because nothing in the returned outputs
   relates to LIPKEY.  This is necessary, because LIPKEY context tokens
   do not have provision for specifying anonymous initiators. This is
   because SPKM-3 is sufficient for purpose of supporting anonymous
   initiators in a low infrastructure environment.

   Clearly, when the LIPKEY caller desires anonymous authentication,
   LIPKEY does not add any value, but it is simpler to support the
   feature, than to insist the caller directly use SPKM-3.






Eisler                      Standards Track                    [Page 12]

RFC 2847                         LIPKEY                        June 2000


   If all goes well, the caller of LIPKEY will be returned a
   major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and so the caller
   of LIPKEY will send the output_token to the target.  The caller of
   LIPKEY then receives the response token from the target, and directly
   invokes the SPKM-3 GSS_Init_sec_context.  Upon return, the
   major_status should be GSS_S_COMPLETE.

3.2.3.2.  LIPKEY Caller Specified anon_req_flag as FALSE

   The LIPKEY mechanism will need to allocate a context handle for
   itself, and record in the LIPKEY context handle the SPKM-3 context
   handle that was returned in the output_context_handle parameter from
   the call to the SPKM-3 GSS_Init_sec_context routine.  The LIPKEY
   GSS_Init_sec_context routine will return in output_context_handle the
   LIPKEY context handle, and in mech_type, the LIPKEY mechanism type.
   The output_token is as defined later in this memorandum, in the
   subsection entitled "Context Tokens Prior to SPKM-3 Context
   Establishment."  All the other returned outputs will be those that
   the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all
   went well, the SPKM-3 mechanism will have returned a major_status of
   GSS_S_CONTINUE_NEEDED.

   The caller of the LIPKEY GSS_Init_sec_context routine will see a
   major_status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY
   will send the output_token to the target. The caller of LIPKEY then
   receives the target's response token, and invokes the LIPKEY
   GSS_Init_sec_context routine for a second time. LIPKEY then invokes
   the SPKM-3 GSS_Init_sec_context for a second time and upon return,
   the major_status should be GSS_S_COMPLETE.

   While SPKM-3's context establishment is now complete, LIPKEY's
   context establishment is not yet complete, because the initiator must
   send to the target the user name and password that were passed to it
   via the claimant_cred_handle on the first call to the LIPKEY
   GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3
   context handle as the input to GSS_Wrap (with conf_req_flag set to
   TRUE) to encrypt what the claimant_cred_handle refers to (user name
   and password), and returns that as the output_token to the caller of
   LIPKEY (provided the conf_state output from the call to SPKM-3's
   GSS_Wrap is TRUE), along with a major_status of
   GSS_S_CONTINUE_NEEDED.

   The caller of LIPKEY sends its second context establishment token to
   the target, and waits for a token provided by the target's
   GSS_Accept_sec_context routine. The target's LIPKEY
   GSS_Accept_sec_context routine invokes the SPKM-3 GSS_Unwrap routine
   on the token, and validates the user name and password.  The target
   then invokes SPKM-3's GSS_Wrap routine on a boolean indicating



Eisler                      Standards Track                    [Page 13]

RFC 2847                         LIPKEY                        June 2000


   whether or not the user name and password were accepted, and returns
   the output_message result from GSS_Wrap as the output_token result
   for GSS_Accept_sec_context.

   The caller of LIPKEY receives the target's response token, and passes
   this via the input_token parameter to the LIPKEY GSS_Init_sec_context
   routine.  LIPKEY then invokes GSS_Unwrap to get the boolean
   acceptance indication, and maps this to a major_status of either
   GSS_S_COMPLETE indicating successful (the boolean was TRUE) and
   completed LIPKEY context establishment, or GSS_S_FAILURE, indicating
   that context establishment failed.  GSS_S_CONTINUE_NEEDED will not be
   returned.

   Note that the mutual_req_flag parameter is ignored because unilateral
   authentication is impossible.  The initiator must authenticate the
   target via SPKM-3 in order to create a secure channel to transmit the
   user name and password. The target must authenticate the initiator
   when it receives the user name and password.

   The SPKM-3 context remains established while the LIPKEY context is
   established.  If the SPKM-3 context expires before the LIPKEY context
   is destroyed, the LIPKEY implementation should expire the LIPKEY
   context and return the appropriate error on the next GSS-API
   operation.

3.2.4.  Other operations

   For other operations, the LIPKEY context acts as a pass through to
   the SPKM-3 context. Operations that affect or inquire context state,
   such as GSS_Delete_sec_context, GSS_Export_sec_context,
   GSS_Import_sec_context, and GSS_Inquire_context will require a pass
   through to the SPKM-3 context and a state modification of the LIPKEY
   context.

3.3.  Target

3.3.1.  GSS_Import_name

   As with the initiator, the imported name will be that of the target.

3.3.2.  GSS_Acquire_cred

   The target calls the LIPKEY GSS_Acquire_cred routine to get a
   credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred
   routine. The desired_name is the output_name from GSS_Import_name.






Eisler                      Standards Track                    [Page 14]

RFC 2847                         LIPKEY                        June 2000


3.3.3.  GSS_Accept_sec_context

   When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism
   type, if the context handle is NULL, the LIPKEY mechanism will in
   turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented
   according the requirements described previously. This call to SPKM-3
   is no different than what one would expect for a layered call to
   GSS_Accept_sec_context.

   If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds
   with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call
   returns the output_token to the caller, but with a major_status of
   GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected
   to send the user name and password.

   Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token
   the target receives will contain the user name and password, wrapped
   by the output of an SPKM-3 GSS_Wrap call. The target invokes the
   LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3
   GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then
   compares the user name and password with its user name name and
   password database.  If the initiator's user name and password are
   valid, GSS_S_COMPLETE is returned to the caller.  Otherwise
   GSS_S_FAILURE is returned. In either case, an output_token - equal to
   the output_message result from an SPKM-3 GSS_Wrap call on a boolean
   value - is returned to the caller.  The boolean value is set to TRUE
   if the the user name and password were valid, FALSE otherwise. The
   target expects no more context establishment tokens from caller.

4.  LIPKEY Description

4.1.  Mechanism Type

   lipkey OBJECT IDENTIFIER ::=
      {iso(1)identified-organization(3)dod(6)internet(1)security(5)
      mechanisms(5)lipkey(9)}

4.2.  Name Types

   LIPKEY uses only the mechanism independent name types defined in RFC
   2078. All the name types defined in RFC 2078 are REQUIRED.










Eisler                      Standards Track                    [Page 15]

RFC 2847                         LIPKEY                        June 2000


4.3.  Token Formats

4.3.1.  Context Tokens

   GSS-API defines the context tokens as:

      InitialContextToken ::=
      -- option indication (delegation, etc.) indicated within
      -- mechanism-specific token
      [APPLICATION 0] IMPLICIT SEQUENCE {
             thisMech MechType,
             innerContextToken ANY DEFINED BY thisMech
                -- contents mechanism-specific
                -- ASN.1 structure not required
      }

      SubsequentContextToken ::= innerContextToken ANY
      -- interpretation based on predecessor InitialContextToken
      -- ASN.1 structure not required

   The contents of the innerContextToken depend on whether the SPKM-3
   context is established or not.

4.3.1.1.  Context Tokens Prior to SPKM-3 Context Establishment

   In a LIPKEY InitialContextToken, thisMech will be the Object
   identifier for LIPKEY.  However, as long as LIPKEY has not
   established the SPKM-3 mechanism, the innerContextToken for both the
   InitialContextToken and the SubsequentContextToken will be the output
   of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context.  So the
   LIPKEY innerContextToken would be either:

   *    An InitialContextToken, with thisMech set to the object
        identifier for SPKM-3, with innerContextToken defined to be an
        SPKMInnerContextToken, as defined in RFC 2025.

   *    A SubsequentContextToken, with innerContextToken defined to be
        SPKMInnerContextToken

4.3.1.2.  Post-SPKM-3 Context Establishment Tokens

   Once the SPKM-3 context is established, there is just one token sent
   from the initiator to the target, and one token returned to
   initiator.







Eisler                      Standards Track                    [Page 16]

RFC 2847                         LIPKEY                        June 2000


4.3.1.2.1.  From LIPKEY Initiator

   The LIPKEY initiator generates a token that is the the result of a
   GSS_Wrap (conf_req is set to TRUE) of a user name and password by the
   SPKM-3 context.  The input_message argument of GSS_Wrap refers to an
   instance of the UserName-Password type defined below:

      UserName-Password ::= SEQUENCE {
              user-name       OCTET STRING,
                                      -- each octet is an octet of a
                                      -- UTF-8 [RFC2279] string
              password        OCTET STRING
                                      -- each octet is an octet of a
                                      -- UTF-8 [RFC2279] string
      }

4.3.1.2.2.  From LIPKEY Target

   The target validates the user name and password token from the
   initiator, and generates a response token that is the output_message
   result of an SPKM-3 GSS_Wrap (conf_req may or may not be set to TRUE)
   call on an indication of validation success. The input_message
   argument of GSS_Wrap refers to an instance of the Valid-UNP type
   defined below:

      Valid-UNP ::= BOOLEAN
                      -- If TRUE, user name/password pair was valid.

4.3.2.  Tokens from GSS_GetMIC and GSS_Wrap

   RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
             PerMsgToken ::=
             -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
             -- ASN.1 structure not required
                     innerMsgToken ANY

             SealedMessage ::=
             -- as emitted by GSS_Wrap and processed by GSS_Unwrap
             -- includes internal, mechanism-defined indicator
             -- of whether or not encrypted
             -- ASN.1 structure not required
                     sealedUserData ANY

   As one can see, there are no mechanism independent prefixes in
   PerMSGToken or SealedMessage, and no explicit mechanism specific
   information. Since LIPKEY does not add any value to GSS_GetMIC and





Eisler                      Standards Track                    [Page 17]

RFC 2847                         LIPKEY                        June 2000


   GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC and
   GSS_Wrap, LIPKEY's PerMsgToken and SealedMessage tokens are exactly
   what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce.

4.4.  Quality of Protection

   LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3,
   does not interpret or alter the QOPs passed to the aforementioned
   routines or received from their complements, GSS_Unwrap, and
   GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3.

5.  Security Considerations

5.1.  Password Management

   LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so
   the risk in this approach is in how the target manages the password
   after it is done with it. The approach should be safe, provided the
   target clears the memory (primary and secondary, such as disk)
   buffers that contained the password, and any hash of the password
   immediately after it has validated the user's password.

5.2.  Certification Authorities

   The initiator must have a list of trusted Certification Authorities
   in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's
   context reply token. If it encounters a certificate signed by an
   unknown and/or untrusted certificate authority, the initiator MUST
   NOT silently accept the certificate. If it does wish to accept the
   certificate, it MUST get confirmation from the user running the
   application that is using GSS-API.

5.3.  HMAC-MD5 and MD5 Weaknesses

   While the MD5 hash algorithm has been found to have weaknesses
   [Dobbertin], the weaknesses do not impact the security of HMAC-MD5
   [Dobbertin].

5.4.  Security of cast5CBC

   The cast5CBC encryption algorithm is relatively new compared to
   established algorithms like triple DES, and RC4. Nonetheless, the
   choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable.
   The cast5CBC algorithm is a 128 bit algorithm that the 256 bit
   cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm
   was judged by the U.S. National Institute of Standards and Technology
   (NIST) to have no known major or minor "security gaps," and to have a
   "high security margin" [AES]. NIST did note some vulnerabilities



Eisler                      Standards Track                    [Page 18]

RFC 2847                         LIPKEY                        June 2000


   related to smart card implementations, but many other algorithms NIST
   analyzed shared the vulnerabilities, and in any case, LIPKEY is by
   definition not aimed at smart cards.

References

   [AES]       Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti,
               J., Roback, E. (Undated, but no later than 1999). "Status
               Report on the First Round of the Development of the
               Advanced Encryption Standard."
               http://csrc.nist.gov/encryption/aes/round1/r1report.htm

   [CCITT]     CCITT (1988). "Recommendation X.208: Specification of
               Abstract Syntax Notation One (ASN.1)."

   [Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent
               Attack," RSA Laboratories' CryptoBytes, Volume 2, Number
               2.
               ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf

   [EFF]       Electronic Frontier Foundation, John Gilmore (Editor)
               (1998). "Cracking Des: Secrets of Encryption Research,
               Wiretap Politics & Chip Design," O'Reilly & Associates,
               ISBN 1565925203.

   [FIPS]      National Institute of Standards and Technology (1995).
               "Secure Hash Standard" (SHA-1).
               http://www.itl.nist.gov/fipspubs/fip180-1.htm

   [IANA]      Internet Assigned Numbers Authority (1999). "Network
               Management Parameters."  http://www.isi.edu/in-
               notes/iana/assignments/smi-numbers

   [PKCS-3]    RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-
               Agreement Standard, Version 1.4."
               ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc

   [PKIX]      Housley, R., Ford, W., Polk, W., Solo, D., "Internet
               X.509 Public Key Infrastructure Certificate and CRL
               Profile", Work in Progress.

   [RFC1831]   Srinivasan, R., "RPC: Remote Procedure Call Protocol
               Specification Version 2", RFC 1831, August 1995.

   [RFC1832]   Srinivasan, R., "XDR: External Data Representation
               Standard", RFC 1832, August 1995.





Eisler                      Standards Track                    [Page 19]

RFC 2847                         LIPKEY                        June 2000


   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
               1964, June 1996.

   [RFC2203]   Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
               Specification", RFC 2203, September 1997.

   [RFC2025]   Adams, C., "The Simple Public-Key GSS-API Mechanism
               (SPKM)", RFC 2025, October 1996.

   [RFC2078]   Linn, J., "Generic Security Service Application Program
               Interface, Version 2", RFC 2078, January 1997.

   [RFC2104]   Krawczyk, H, Bellare, M. and R. Canetti, "HMAC:  Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]   Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
               May 1997.

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [RFC2279]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", RFC 2279, January 1998.

   [RFC2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
               Specifications Version 2.0", RFC 2437, October 1998.

   [RFC2459]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
               X.509 Public Key Infrastructure Certificate and CRL
               Profile", RFC 2459, January 1999.

   [RFC2612]  Adams, C. and J. Gilchrist, "The CAST-256 Encryption
               Algorithm", RFC 2612, June 1999.

   [RSA-IP]   All statements received by the IETF Secretariat are places
               on-line in http://www.ietf.org/ipr.html.  Please check
               this web page to see any IPR information received about
               this and other technology.

   [Sandberg]  Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
               B. (1985). "Design and Implementation of the Sun Network
               Filesystem,"  Proceedings of the 1985 Summer USENIX
               Technical Conference.




Eisler                      Standards Track                    [Page 20]

RFC 2847                         LIPKEY                        June 2000


   [Schneier]  Schneier, B. (1996). "Applied Cryptography," John Wiley &
               Sons, Inc., ISBN 0-471-11709-9.

   [Young]     Young, E.A. (1997). Collected timing results from the
               SSLeay source code distribution.

Acknowledgments

   The author thanks and acknowledges:

   *    Jack Kabat for his patient explanation of the intricacies of
        SPKM, excellent suggestions, and review comments.

   *    Denis Pinkas for his review comments.

   *    Carlisle Adams for his review comments.

   *    John Linn for his review comments.

   *    Martin Rex for his review comments.

   *    This memorandum includes ASN.1 definitions for GSS-API tokens
        from RFC 2078, which was authored by John Linn.

   *    This memorandum includes ASN.1 definitions and other text from
        the SPKM definition in RFC 2025, which was authored by Carlisle
        Adams.

Author's Address

   Address comments related to this memorandum to:

   ietf-cat-wg@lists.Stanford.EDU

   Mike Eisler
   Zambeel
   5565 Wilson Road
   Colorado Springs, CO 80919

   Phone: 1-719-599-9026
   EMail: mike@eisler.com










Eisler                      Standards Track                    [Page 21]

RFC 2847                         LIPKEY                        June 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Eisler                      Standards Track                    [Page 22]