4
Internet Engineering Task Force K. Jaganathan
6
Expires: January 9, 2006 J. Brezak
11
The RC4-HMAC Kerberos encryption type
12
draft-jaganathan-rc4-hmac-00.txt
16
By submitting this Internet-Draft, each author represents that any
17
applicable patent or other IPR claims of which he or she is aware
18
have been or will be disclosed, and any of which he or she becomes
19
aware will be disclosed, in accordance with Section 6 of BCP 79.
21
Internet-Drafts are working documents of the Internet Engineering
22
Task Force (IETF), its areas, and its working groups. Note that
23
other groups may also distribute working documents as Internet-
26
Internet-Drafts are draft documents valid for a maximum of six months
27
and may be updated, replaced, or obsoleted by other documents at any
28
time. It is inappropriate to use Internet-Drafts as reference
29
material or to cite them other than as "work in progress."
31
The list of current Internet-Drafts can be accessed at
32
http://www.ietf.org/ietf/1id-abstracts.txt.
34
The list of Internet-Draft Shadow Directories can be accessed at
35
http://www.ietf.org/shadow.html.
37
This Internet-Draft will expire on January 9, 2006.
41
Copyright (C) The Internet Society (2005).
45
The Microsoft Windows 2000 implementation of Kerberos introduces a
46
new encryption type based on the RC4 encryption algorithm and using
47
an MD5 HMAC for checksum. This is offered as an alternative to using
48
the existing DES based encryption types.
50
The RC4-HMAC encryption types are used to ease upgrade of existing
51
Windows NT environments, provide strong crypto (128-bit key lengths),
55
Jaganathan, et al. Expires January 9, 2006 [Page 1]
57
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
60
and provide exportable (meet United States government export
61
restriction requirements) encryption. This document describes the
62
implementation of those encryption types.
66
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
67
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
68
3. Key Generation . . . . . . . . . . . . . . . . . . . . . . . . 5
69
4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 6
70
5. Checksum Types . . . . . . . . . . . . . . . . . . . . . . . . 8
71
6. Encryption Types . . . . . . . . . . . . . . . . . . . . . . . 9
72
7. Key Strength Negotiation . . . . . . . . . . . . . . . . . . . 12
73
8. GSSAPI Kerberos V5 Mechanism Type . . . . . . . . . . . . . . 13
74
8.1 Mechanism Specific Changes . . . . . . . . . . . . . . . . 13
75
8.2 GSSAPI MIC Semantics . . . . . . . . . . . . . . . . . . . 14
76
8.3 GSSAPI WRAP Semantics . . . . . . . . . . . . . . . . . . 16
77
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
78
10. Normative References . . . . . . . . . . . . . . . . . . . . 20
79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
80
Intellectual Property and Copyright Statements . . . . . . . . 22
111
Jaganathan, et al. Expires January 9, 2006 [Page 2]
113
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
118
The Microsoft Windows 2000 implementation of Kerberos contains new
119
encryption and checksum types for two reasons: for export reasons
120
early in the development process, 56 bit DES encryption could not be
121
exported, and because upon upgrade from Windows NT 4.0 to Windows
122
2000, accounts will not have the appropriate DES keying material to
123
do the standard DES encryption. Furthermore, 3DES is not available
124
for export, and there was a desire to use a single flavor of
125
encryption in the product for both US and international products.
127
As a result, there are two new encryption types and one new checksum
128
type introduced in Microsoft Windows 2000.
167
Jaganathan, et al. Expires January 9, 2006 [Page 3]
169
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
172
2. Conventions Used in This Document
174
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176
document are to be interpreted as described in [RFC2119].
223
Jaganathan, et al. Expires January 9, 2006 [Page 4]
225
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
230
On upgrade from existing Windows NT domains, the user accounts would
231
not have a DES based key available to enable the use of DES base
232
encryption types specified in RFC 1510. The key used for RC4-HMAC is
233
the same as the existing Windows NT key (NT Password Hash) for
234
compatibility reasons. Once the account password is changed, the DES
235
based keys are created and maintained. Once the DES keys are
236
available DES based encryption types can be used with Kerberos.
238
The RC4-HMAC String to key function is defined as follow:
242
K = MD4(UNICODE(password))
244
The RC4-HMAC keys are generated by using the Windows UNICODE version
245
of the password. Each Windows UNICODE character is encoded in
246
little-endian format of 2 octets each. Then performing an MD4
247
[RFC1320] hash operation on just the UNICODE characters of the
248
password (not including the terminating zero octets).
250
For an account with a password of "foo", this String2Key("foo") will
253
0xac, 0x8e, 0x65, 0x7f, 0x83, 0xdf, 0x82, 0xbe,
254
0xea, 0x5d, 0x43, 0xbd, 0xaf, 0x78, 0x00, 0xcc
279
Jaganathan, et al. Expires January 9, 2006 [Page 5]
281
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
286
The MD5 HMAC function is defined in [RFC2104]. It is used in this
287
encryption type for checksum operations. Refer to [RFC2104] for
288
details on its operation. In this document this function is referred
289
to as HMAC(Key, Data) returning the checksum using the specified key
292
The basic MD5 hash operation is used in this encryption type and
293
defined in [RFC1321]. In this document this function is referred to
294
as MD5(Data) returning the checksum of the data.
296
RC4 is a stream cipher licensed by RSA Data Security . In this
297
document the function is referred to as RC4(Key, Data) returning the
298
encrypted data using the specified key on the data.
300
These encryption types use key derivation. With each message, the
301
message type (T) is used as a component of the keying material. This
302
table summarizes the different key derivation values used in the
303
various operations. Note that these differ from the key derivations
304
used in other Kerberos encryption types. T = the message type,
305
encoded as a little-endian four byte integer.
335
Jaganathan, et al. Expires January 9, 2006 [Page 6]
337
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
340
1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
342
2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key
343
or application session key), encrypted with the service key
345
3. AS-REP encrypted part (includes TGS session key or
346
application session key), encrypted with the client key (T=8)
347
4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
348
TGS session key (T=4)
349
5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the
350
TGS authenticator subkey (T=5)
351
6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
352
keyed with the TGS session key (T=6)
353
7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
354
TGS authenticator subkey), encrypted with the TGS session key
356
8. TGS-REP encrypted part (includes application session key),
357
encrypted with the TGS session key (T=8)
358
9. TGS-REP encrypted part (includes application session key),
359
encrypted with the TGS authenticator subkey (T=8)
360
10. AP-REQ Authenticator cksum, keyed with the application
362
11. AP-REQ Authenticator (includes application authenticator
363
subkey), encrypted with the application session key (T=11)
364
12. AP-REP encrypted part (includes application session
365
subkey), encrypted with the application session key (T=12)
366
13. KRB-PRIV encrypted part, encrypted with a key chosen by
367
the application. Also for data encrypted with GSS Wrap (T=13)
368
14. KRB-CRED encrypted part, encrypted with a key chosen by
369
the application (T=14)
370
15. KRB-SAFE cksum, keyed with a key chosen by the
371
application. Also for data signed in GSS MIC (T=15)
373
Relative to RFC-1964 key uses:
375
T = 0 in the generation of sequence number for the MIC token
376
T = 0 in the generation of sequence number for the WRAP token
377
T = 0 in the generation of encrypted data for the WRAPPED token
379
All strings in this document are ASCII unless otherwise specified.
380
The lengths of ASCII encoded character strings include the trailing
381
terminator character (0). The concat(a,b,c,...) function will return
382
the logical concatenation (left to right) of the values of the
383
arguments. The nonce(n) function returns a pseudo-random number of
391
Jaganathan, et al. Expires January 9, 2006 [Page 7]
393
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
398
There is one checksum type used in this encryption type. The
399
Kerberos constant for this type is:
401
#define KERB_CHECKSUM_HMAC_MD5 (-138)
403
The function is defined as follows:
406
T - the message type, encoded as a little-endian four byte integer
410
Ksign = HMAC(K, "signaturekey") //includes zero octet at end
411
tmp = MD5(concat(T, data))
412
CHKSUM = HMAC(Ksign, tmp)
447
Jaganathan, et al. Expires January 9, 2006 [Page 8]
449
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
454
There are two encryption types used in these encryption types. The
455
Kerberos constants for these types are:
457
#define KERB_ETYPE_RC4_HMAC 23
458
#define KERB_ETYPE_RC4_HMAC_EXP 24
460
The basic encryption function is defined as follow:
462
T = the message type, encoded as a little-endian four byte integer.
464
OCTET L40[14] = "fortybits";
465
OCTET SK = "signaturekey";
467
The header field on the encrypted data in KDC messages is:
469
typedef struct _RC4_MDx_HEADER {
472
} RC4_MDx_HEADER, *PRC4_MDx_HEADER;
475
ENCRYPT (K, export, T, data)
486
*((DWORD *)(L40+10)) = T;
487
HMAC (K, L40, 10 + 4, K1);
494
if (export) memset (K1+7, 0xAB, 9);
496
nonce (edata.Confounder, 8);
497
memcpy (edata.Data, data);
499
edata.Checksum = HMAC (K2, edata);
503
Jaganathan, et al. Expires January 9, 2006 [Page 9]
505
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
508
K3 = HMAC (K1, edata.Checksum);
510
RC4 (K3, edata.Confounder);
514
DECRYPT (K, export, T, edata)
526
*((DWORD *)(L40+10)) = T;
527
HMAC (K, L40, 14, K1);
534
if (export) memset (K1+7, 0xAB, 9);
536
K3 = HMAC (K1, edata.Checksum);
538
RC4 (K3, edata.Confounder);
539
RC4 (K3, edata.Data);
542
// verify generated and received checksums
543
checksum = HMAC (K2, concat(edata.Confounder, edata.Data));
544
if (checksum != edata.Checksum)
545
printf("CHECKSUM ERROR !!!!!!\n");
548
The KDC message is encrypted using the ENCRYPT function not including
549
the Checksum in the RC4_MDx_HEADER.
551
The character constant "fortybits" evolved from the time when a 40-
552
bit key length was all that was exportable from the United States.
553
It is now used to recognize that the key length is of "exportable"
554
length. In this description, the key size is actually 56-bits.
559
Jaganathan, et al. Expires January 9, 2006 [Page 10]
561
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
564
The pseudo-random operation [RFC3961] for both enctypes above is
567
pseudo-random(K, S) = HMAC-SHA1(K, S)
569
where K is the protocol key and S is the input octet string. HMAC-
570
SHA1 is defined in [RFC2104] and the output of HMAC-SHA1 is the 20-
615
Jaganathan, et al. Expires January 9, 2006 [Page 11]
617
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
620
7. Key Strength Negotiation
622
A Kerberos client and server can negotiate over key length if they
623
are using mutual authentication. If the client is unable to perform
624
full strength encryption, it may propose a key in the "subkey" field
625
of the authenticator, using a weaker encryption type. The server
626
must then either return the same key or suggest its own key in the
627
subkey field of the AP reply message. The key used to encrypt data
628
is derived from the key returned by the server. If the client is
629
able to perform strong encryption but the server is not, it may
630
propose a subkey in the AP reply without first being sent a subkey in
671
Jaganathan, et al. Expires January 9, 2006 [Page 12]
673
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
676
8. GSSAPI Kerberos V5 Mechanism Type
678
8.1 Mechanism Specific Changes
680
The GSSAPI per-message tokens also require new checksum and
681
encryption types. The GSS-API per-message tokens are adapted to
682
support these new encryption types. See [RFC1964] Section 1.2.2.
684
The only support quality of protection is:
686
#define GSS_KRB5_INTEG_C_QOP_DEFAULT 0x0
688
When using this RC4 based encryption type, the sequence number is
689
always sent in big-endian rather than little-endian order.
691
The Windows 2000 implementation also defines new GSSAPI flags in the
692
initial token passed when initializing a security context. These
693
flags are passed in the checksum field of the authenticator. See
694
[RFC1964] Section 1.1.1.
696
GSS_C_DCE_STYLE - This flag was added for use with Microsoft's
697
implementation of DCE RPC, which initially expected three legs of
698
authentication. Setting this flag causes an extra AP reply to be
699
sent from the client back to the server after receiving the server's
700
AP reply. In addition, the context negotiation tokens do not have
701
GSSAPI per message tokens - they are raw AP messages that do not
702
include object identifiers.
704
#define GSS_C_DCE_STYLE 0x1000
706
GSS_C_IDENTIFY_FLAG - This flag allows the client to indicate to the
707
server that it should only allow the server application to identify
708
the client by name and ID, but not to impersonate the client.
710
#define GSS_C_IDENTIFY_FLAG 0x2000
712
GSS_C_EXTENDED_ERROR_FLAG - Setting this flag indicates that the
713
client wants to be informed of extended error information. In
714
particular, Windows 2000 status codes may be returned in the data
715
field of a Kerberos error message. This allows the client to
716
understand a server failure more precisely. In addition, the server
717
may return errors to the client that are normally handled at the
718
application layer in the server, in order to let the client try to
719
recover. After receiving an error message, the client may attempt to
720
resubmit an AP request.
722
#define GSS_C_EXTENDED_ERROR_FLAG 0x4000
727
Jaganathan, et al. Expires January 9, 2006 [Page 13]
729
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
732
These flags are only used if a client is aware of these conventions
733
when using the SSPI on the Windows platform; they are not generally
736
When NetBIOS addresses are used in the GSSAPI, they are identified by
737
the GSS_C_AF_NETBIOS value. This value is defined as:
739
#define GSS_C_AF_NETBIOS 0x14
741
NetBios addresses are 16-octet addresses typically composed of 1 to
742
15 characters, trailing blank (ASCII char 20) filled, with a 16-th
745
8.2 GSSAPI MIC Semantics
747
The GSSAPI checksum type and algorithm is defined in Section 5. Only
748
the first 8 octets of the checksum are used. The resulting checksum
749
is stored in the SGN_CKSUM field . See [RFC1964] Section 1.2 for
750
GSS_GetMIC() and GSS_Wrap(conf_flag=FALSE).
752
The GSS_GetMIC token has the following format:
754
Byte no Name Description
755
0..1 TOK_ID Identification field.
756
Tokens emitted by GSS_GetMIC() contain
757
the hex value 01 01 in this field.
758
2..3 SGN_ALG Integrity algorithm indicator.
760
4..7 Filler Contains ff ff ff ff
761
8..15 SND_SEQ Sequence number field.
762
16..23 SGN_CKSUM Checksum of "to-be-signed data",
763
calculated according to algorithm
764
specified in SGN_ALG field.
766
The MIC mechanism used for GSS MIC based messages is as follow:
768
GetMIC(Kss, direction, export, seq_num, data)
783
Jaganathan, et al. Expires January 9, 2006 [Page 14]
785
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
788
Token.TOK_ID = 01 01;
789
Token.SGN_SLG = 11 00;
790
Token.Filler = ff ff ff ff;
792
// Create the sequence number
794
if (direction == sender_is_initiator)
796
memset(Token.SEND_SEQ+4, 0xff, 4)
798
else if (direction == sender_is_acceptor)
800
memset(Token.SEND_SEQ+4, 0, 4)
802
Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
803
Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
804
Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
805
Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
807
// Derive signing key from session key
809
Ksign = HMAC(Kss, "signaturekey");
810
// length includes terminating null
812
// Generate checksum of message - SGN_CKSUM
813
// Key derivation salt = 15
815
Sgn_Cksum = MD5((int32)15, Token.Header, data);
817
// Save first 8 octets of HMAC Sgn_Cksum
819
Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
820
memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
822
// Encrypt the sequence number
824
// Derive encryption key for the sequence number
825
// Key derivation salt = 0
829
Kseq = HMAC(Kss, "fortybits", (int32)0);
830
// len includes terminating null
831
memset(Kseq+7, 0xab, 7)
835
Kseq = HMAC(Kss, (int32)0);
839
Jaganathan, et al. Expires January 9, 2006 [Page 15]
841
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
845
Kseq = HMAC(Kseq, Token.SGN_CKSUM);
847
// Encrypt the sequence number
849
RC4(Kseq, Token.SND_SEQ);
853
8.3 GSSAPI WRAP Semantics
855
There are two encryption keys for GSSAPI message tokens, one that is
856
128 bits in strength, and one that is 56 bits in strength as defined
859
All padding is rounded up to 1 byte. One byte is needed to say that
860
there is 1 byte of padding. The DES based mechanism type uses 8 byte
861
padding. See [RFC1964] Section 1.2.2.3.
863
The RC4-HMAC GSS_Wrap() token has the following format:
866
Byte no Name Description
867
0..1 TOK_ID Identification field.
868
Tokens emitted by GSS_Wrap() contain
869
the hex value 02 01 in this field.
870
2..3 SGN_ALG Checksum algorithm indicator.
872
4..5 SEAL_ALG ff ff - none
875
6..7 Filler Contains ff ff
876
8..15 SND_SEQ Encrypted sequence number field.
877
16..23 SGN_CKSUM Checksum of plaintext padded data,
878
calculated according to algorithm
879
specified in SGN_ALG field.
880
24..31 Confounder Random confounder
881
32..last Data encrypted or plaintext padded data
883
The encryption mechanism used for GSS wrap based messages is as
887
WRAP(Kss, encrypt, direction, export, seq_num, data)
889
struct Token { // 32 octets
895
Jaganathan, et al. Expires January 9, 2006 [Page 16]
897
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
910
Token.TOK_ID = 02 01;
911
Token.SGN_SLG = 11 00;
912
Token.SEAL_ALG = (no_encrypt)? ff ff : 10 00;
913
Token.Filler = ff ff;
915
// Create the sequence number
917
if (direction == sender_is_initiator)
919
memset(&Token.SEND_SEQ[4], 0xff, 4)
921
else if (direction == sender_is_acceptor)
923
memset(&Token.SEND_SEQ[4], 0, 4)
925
Token.SEND_SEQ[0] = (seq_num & 0xff000000) >> 24;
926
Token.SEND_SEQ[1] = (seq_num & 0x00ff0000) >> 16;
927
Token.SEND_SEQ[2] = (seq_num & 0x0000ff00) >> 8;
928
Token.SEND_SEQ[3] = (seq_num & 0x000000ff);
930
// Generate random confounder
932
nonce(&Token.Confounder, 8);
934
// Derive signing key from session key
936
Ksign = HMAC(Kss, "signaturekey");
938
// Generate checksum of message -
939
// SGN_CKSUM + Token.Confounder
940
// Key derivation salt = 15
942
Sgn_Cksum = MD5((int32)15, Token.Header,
945
// Derive encryption key for data
946
// Key derivation salt = 0
951
Jaganathan, et al. Expires January 9, 2006 [Page 17]
953
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
956
for (i = 0; i < 16; i++) Klocal[i] = Kss[i] ^ 0xF0;
960
Kcrypt = HMAC(Klocal, "fortybits", (int32)0);
961
// len includes terminating null
962
memset(Kcrypt+7, 0xab, 7);
966
Kcrypt = HMAC(Klocal, (int32)0);
969
// new encryption key salted with seq
971
Kcrypt = HMAC(Kcrypt, (int32)seq);
973
// Encrypt confounder (if encrypting)
976
RC4(Kcrypt, Token.Confounder);
978
// Sum the data buffer
980
Sgn_Cksum += MD5(data); // Append to checksum
982
// Encrypt the data (if encrypting)
987
// Save first 8 octets of HMAC Sgn_Cksum
989
Sgn_Cksum = HMAC(Ksign, Sgn_Cksum);
990
memcpy(Token.SGN_CKSUM, Sgn_Cksum, 8);
992
// Derive encryption key for the sequence number
993
// Key derivation salt = 0
997
Kseq = HMAC(Kss, "fortybits", (int32)0);
998
// len includes terminating null
999
memset(Kseq+7, 0xab, 7)
1003
Kseq = HMAC(Kss, (int32)0);
1007
Jaganathan, et al. Expires January 9, 2006 [Page 18]
1009
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1013
Kseq = HMAC(Kseq, Token.SGN_CKSUM);
1015
// Encrypt the sequence number
1017
RC4(Kseq, Token.SND_SEQ);
1019
// Encrypted message = Token + Data
1022
The character constant "fortybits" evolved from the time when a 40-
1023
bit key length was all that was exportable from the United States.
1024
It is now used to recognize that the key length is of "exportable"
1025
length. In this description, the key size is actually 56-bits.
1063
Jaganathan, et al. Expires January 9, 2006 [Page 19]
1065
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1068
9. Security Considerations
1070
Care must be taken in implementing this encryption type because it
1071
uses a stream cipher. If a different IV isn't used in each direction
1072
when using a session key, the encryption is weak. By using the
1073
sequence number as an IV, this is avoided.
1075
10. Normative References
1077
[RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
1080
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1083
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
1084
Authentication Service (V5)", RFC 1510, September 1993.
1086
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1087
RFC 1964, June 1996.
1089
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1090
Hashing for Message Authentication", RFC 2104,
1093
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1094
Requirement Levels", BCP 14, RFC 2119, March 1997.
1096
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1097
Kerberos 5", RFC 3961, February 2005.
1103
Microsoft Corporation
1108
Email: karthikj@microsoft.com
1119
Jaganathan, et al. Expires January 9, 2006 [Page 20]
1121
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1125
Microsoft Corporation
1130
Email: lzhu@microsoft.com
1134
Microsoft Corporation
1139
Email: jbrezak@microsoft.com
1175
Jaganathan, et al. Expires January 9, 2006 [Page 21]
1177
Internet-Draft The RC4-HMAC Kerberos encryption type July 2005
1180
Intellectual Property Statement
1182
The IETF takes no position regarding the validity or scope of any
1183
Intellectual Property Rights or other rights that might be claimed to
1184
pertain to the implementation or use of the technology described in
1185
this document or the extent to which any license under such rights
1186
might or might not be available; nor does it represent that it has
1187
made any independent effort to identify any such rights. Information
1188
on the procedures with respect to rights in RFC documents can be
1189
found in BCP 78 and BCP 79.
1191
Copies of IPR disclosures made to the IETF Secretariat and any
1192
assurances of licenses to be made available, or the result of an
1193
attempt made to obtain a general license or permission for the use of
1194
such proprietary rights by implementers or users of this
1195
specification can be obtained from the IETF on-line IPR repository at
1196
http://www.ietf.org/ipr.
1198
The IETF invites any interested party to bring to its attention any
1199
copyrights, patents or patent applications, or other proprietary
1200
rights that may cover technology that may be required to implement
1201
this standard. Please address the information to the IETF at
1205
Disclaimer of Validity
1207
This document and the information contained herein are provided on an
1208
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1209
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1210
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1211
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1212
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1213
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1218
Copyright (C) The Internet Society (2005). This document is subject
1219
to the rights, licenses and restrictions contained in BCP 78, and
1220
except as set forth therein, the authors retain all their rights.
1225
Funding for the RFC Editor function is currently provided by the
1231
Jaganathan, et al. Expires January 9, 2006 [Page 22]
added
removed
doc/standardisation/draft-jaganathan-rc4-hmac-00.txt
