Network Working Group                                   Kaushik Narayan
Category :Experimental                                        HCL-Cisco
Title : draft-kaushik-diameter-strong-sec-00.txt          February 2001



          DIAMETER Strong Security Extension using Kerberos v5


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited. It is filed as <draft-
   kaushik-diameter-strong-sec-ext-00.txt>, and expires September 2001. 
   Please send comments to the author (kaushik@cisco.com).


Copyright Notice

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


Abstract

   The DIAMETER base protocol defines message integrity and AVP
   encryption using static symmetric transforms to secure the 
   communication between two DIAMETER nodes. The base protocol 
   also defines a DIAMETER proxy server, that forwards requests 
   to other servers when it detects that a given request cannot 
   be satisfied locally.



Kaushik                    expires September 2001               [Page 1]

Internet-Draft                                             February 2001




   The ROAMOPS Working Group has defined a requirement that allows for
   the DIAMETER servers communicating through the proxy to be able to
   provide for end-to-end AVP integrity and confidentiality, making it
   difficult for the proxy to be able to modify, and/or be able to view
   sensitive information, within the message. The Mobile-IP and NASREQ
   Working Groups have stated that strong authentication is a
   requirement for AAA data, such as accounting records, for the
   purposes of non-repudiation.

   This DIAMETER extension specifies how strong AVP authentication,
   integrity and encryption can be done using by keys negotiated
   using Kerberos v5. 


Table of Contents

      1.0  Introduction
      2.0  Extended AVP Format
      3.0  Encryption operation
      4.0  Integrity Protection operation
      5.0  Kerberized DIAMETER operation
           5.1  End to End DIAMTER Security using Kerberos
           5.2  Hop by Hop Security using Kerberos
           5.3  Kerberos-Data AVP 
           5.4  Kerberos-Endtoend-Auth AVP 
           5.5  Kerberos-Hopbyhop-Auth AVP 
           5.6  Authentication-Transform-ID AVP 
           5.7  Encryption-Transform-ID AVP 
      7.0  References
      8.0  Acknowledgements
      9.0  Authors' Addresses


1.0  Introduction

   The DIAMETER base protocol [1] defines message integrity and AVP
   encryption using symmetric transforms to secure the communication
   between two DIAMETER nodes. The base protocol also defines a 
   DIAMETER proxy server, that forwards requests to other servers 
   when it detects that a given request cannot be satisfied locally.

   The ROAMOPS Working Group has defined a requirement in [10] that
   allows for the DIAMETER servers communicating through the proxy to 
   be able to provide for end-to-end AVP integrity and confidentiality,
   making it difficult for the proxy to be able to modify and see
   sensitive information within the message.  The Mobile-IP and NASREQ
   Working Groups have stated in [6, 7, 8] that non-repudiation is a
   requirement for AAA data, such as accounting records.



Kaushik                    expires September 2001               [Page 2]

Internet-Draft                                             February 2001


   When a chain of proxies use hop-by-hop security, each node in the
   proxy chain MUST recompute the Integrity-Value-Check (ICV) [1],
   making it easy for a malicious proxy to modify information in a
   DIAMETER message. It is virtually impossible for the rest of the
   nodes in the proxy chain to know that the message was modified in
   mid-stream. Figure 1 shows an example of such a network, where DIA3
   modifies the contents of "foo" in both the request and the response.

              (Request)         (Request)         (Request)
             [AVP(foo)=x]      [AVP(foo)=x]      [AVP(foo)=y]
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |          |      |
      | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 |
      |      |          |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
               (Answer)          (Answer)          (Answer)
             [AVP(foo)=b]      [AVP(foo)=b]      [AVP(foo)=a]
                           Figure 1: Proxy Chain

   This document describes how strong authentication and encryption can
   be provided in the DIAMETER protocol, by employing security services
   provided by Kerberos. Kerberos v5 session keys would be negotiated
   between DIAMETER peers and Kerberos v5 messages would be carried in
   the Kerberos-Data ,Kerberos-Endtoend-Auth and Kerberos-Hopbyhop-Auth
   AVPs. 

   In the example provided in Figure 1, the originator of the request
   and response adds a digital signature that covers a set of AVPs
   within the message. The protected AVPs MUST NOT be changed by an
   intermediate proxy server (DIA2, DIA3), since the signature
   validation performed by the end server would fail.


2.0  Extended AVP Format

   This specification introduces the 'P' bit in the AVP Header, which is
   defined in [1]. The 'P' bit, known as the protected AVP bit, is used
   to indicate whether the AVP is protected by a digital signature. When
   set, the AVP is protected and the contents cannot be changed by a
   DIAMETER proxy server without detection.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           AVP Code                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          AVP Length           |     Reserved        |P|R|V|R|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+
                  Figure 4: Extended DIAMETER AVP Header



Kaushik                    expires September 2001               [Page 3]

Internet-Draft                                             February 2001



   Note that unless stated otherwise, the 'P' bit can be set on any
   DIAMETER AVP. The Proxy-State and Integrity-Check-Value AVPs [1] MUST
   NOT have the 'P' bit set. The Encrypted-Payload AVP MAY have the 'P'
   bit set if there is no intermediate proxy server. Any additional AVPs
   that MUST be removed, or changed, at each hop in a proxy chain MUST
   NOT have the 'P' bit set.

3.0 Encryption operation

   The KRB_PRIV message carries the DIAMETER AVPs encrypted in the 
   Session Key. The encrypted DIAMETER AVPs  would be present in the
   user-data field in the EncKrbPrivPart message. As defined in 
   RFC 1510, the following ASN.1 definition describes the KRB_PRIV 
   message

   KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
                pvno[0]                   INTEGER,
                 msg-type[1]               INTEGER,
                enc-part[3]               EncryptedData
   }

   EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
                user-data[0]              OCTET STRING,
                timestamp[1]              KerberosTime OPTIONAL,
                usec[2]                   INTEGER OPTIONAL,
                seq-number[3]             INTEGER OPTIONAL,
                s-address[4]              HostAddress, -- sender's addr
                r-address[5]              HostAddress OPTIONAL
                                                      -- recip's addr
   }

   The enc-part holds an encoding of the EncKrbPrivPart sequence 
   encrypted under the session key. As defined in RFC 1510, the 
   following ASN.1 definition describes the encrypted contents:

   EncryptedData ::=   SEQUENCE {
                       etype[0]     INTEGER, -- EncryptionType
                       kvno[1]      INTEGER OPTIONAL,
                       cipher[2]    OCTET STRING -- ciphertext
   }


   CipherText ::=   ENCRYPTED       SEQUENCE {
        confounder[0]   UNTAGGED OCTET STRING(conf_length)     OPTIONAL,
        check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
        msg-seq[2]      MsgSequence,
        pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
   }



Kaushik                    expires September 2001               [Page 4]

Internet-Draft                                             February 2001



4.0 Integrity Protection operation 

   The KRB_SAFE message carries the integrity protected DIAMETER 
   AVPs. This message is carried along with a collision-proof 
   checksum keyed with the session key. As defined in RFC 1510, the 
   following ASN.1 definition describes the KRB_SAFE message 

   KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
               pvno[0]               INTEGER,
               msg-type[1]           INTEGER,
               safe-body[2]          KRB-SAFE-BODY,
               cksum[3]              Checksum
   }

   KRB-SAFE-BODY ::=   SEQUENCE {
               user-data[0]          OCTET STRING,
               timestamp[1]          KerberosTime OPTIONAL,
               usec[2]               INTEGER OPTIONAL,
               seq-number[3]         INTEGER OPTIONAL,
               s-address[4]          HostAddress,
               r-address[5]          HostAddress OPTIONAL
   }

   As defined in RFC 1510, the following ASN.1 definition is used for
   a checksum:

   Checksum ::=   SEQUENCE {
                           cksumtype[0]   INTEGER,
                           checksum[1]    OCTET STRING
   } 

5.0  Kerberos for DIAMETER strong security

   The word "diameter" is used as the keyword in the Kerberos service 
   principal. The Kerberos V principal for a DIAMETER server called 
   "servername" in the realm "serverrealm" would be 
   diameter/servername.serverrealm@serverrealm.

   The DIAMTER client uses the kerberos service principal for service 
   discovery i.e. to discover the capability of a DIAMETER server to 
   support Kerberos. Since the kerberos service principal is defined 
   per DIAMETER server or proxy only Kerberized DIAMETER servers or 
   proxies would have the service principals registered with the KDC. 
   The KRB_TGS_REQ would fail trying to obtain a ticket for a non 
   Kerberized DIAMETER server or proxy and the NAS would revert back 
   to using the "normal" DIAMETER operation as defined in RFC 2865.



Kaushik                    expires September 2001               [Page 5]

Internet-Draft                                             February 2001





   A valid cross domain Ticket Granting Ticket(TGT) must be cached on 
   the DIAMETER client prior to sending a Kerberized DIAMETER request.  
   Cross domain TGT acquisition is out of the scope of this draft and 
   can happen based on inter domain trust or public key extensions 
   like PKCROSS can be employed to obtain cross realm TGTs. 

   The service principal ticket is acquired from the KDC prior to 
   a Kerberos application exchange. The DIAMETER client will send 
   a KRB_TGS_REQ to the Ticket Granting Service (TGS) in order to 
   the service principal ticket for the DIAMETER server. The TGS will 
   reply with a KRB_TGS_REP, containing a session key and Kerberos 
   ticket to the DIAMETER service. In case the service principal 
   ticket is present in the credentials cache on the DIAMETER client, 
   the KRB_TGS_REQ will not be sent, but the credentials would be 
   retrieved from the cache. The credentials would be cached on the 
   DIAMETER client for a non negligible period of time(can vary from a 
   few hours to months) and the number of transactions between the
   Kerberized DIAMETER clients and the KDC (KRB_TGS_REQ/KRB_TGS_REP)
   would be very small as compared to the transactions between the
   Kerberized DIAMETER peers (KRB_AP_REQ/KRB_AP_REP). The Kerberized
   DIAMETER operation would mostly involve dynamic symmetric key 
   negotiation between DIAMETER peers using the Kerberos Application 
   exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated 
   would then be used to provide integrity protection and privacy 
   protection for the DIAMETER AVPs.

   In routing the Access-Request to the home DIAMETER server, the
   NAI is typically  used, as described in RFC 2486. For NAS to
   homeserver End-to-End security the NAS can determine whether 
   the Access-Request will be served locally, or whether it needs to 
   be proxied based on the NAI. The NAS would also need the hostname 
   of the homeserver construct the End-to-End service principal. The 
   hostname and port of a DIAMETER homeserver can be determined as 
   described in the section 3.4. Remote realm Kerberos Key 
   Distribution Centres(KDC) can either be statically configured or 
   can be discovered dynamically. The internet draft 
   "draft-ietf-cat-krb-dns-locate-02.txt" suggests a method of dynamic 
   discovery of the KDC for a remote realm.
 
5.1   End-to-End DIAMTER Security using Kerberos

   Kerberized DIAMETER would provide end-to-end security between 
   DIAMETER peers, End-to-End security refers to security between 
   the NAS and the homeserver.  This draft can provide NAS to 
   homeserver End to End security without a major compromise in 
   NAS performance since the symmetric key operation and ticket 
   caching make Kerberos exceptionally lightweight. 



Kaushik                    expires September 2001               [Page 6]

Internet-Draft                                             February 2001



   The NAS will start of by creating a KRB_AP_REQ message using the 
   credentials present in the end-to-end service principal ticket. 
   The KRB_AP_REQ will have MUTUAL-REQUIRED and USE_SECRET_KEY 
   set in the ap-options field in order to turn on mutual 
   authentication mode and specify to the homeserver to use its secret 
   key to decrypt the Kerberos ticket. The Kerberos-Endtoend Auth AVP 
   would carry the KRB_AP_REQ/KRB_AP_REP messages.

   If end-to-end security is used, then an end-to-end Integrity 
   Checksum must be present. This prevents a downgrade attack in 
   which an attacker deletes the end-to-end Integrity Checksum and 
   then modifies the reply.  A KRB_SAFE message WOULD be generated 
   by signing on the Command-Code and Identifier field in the 
   DIAMETER header in addition to any DIAMETER AVPs that need to 
   end-to-end Integrity protected using the Kerberos end-to-end 
   session key. Digest AVP in the Kerberos-Data AVP would carry the 
   KRB_SAFE message.
   
   In case there are DIAMETER AVPs that need end-to-end confidentiality
   protection then a KRB_PRIV message WOULD be generated by using the 
   Kerberos end-to-end session key to encrypt the DIAMETER AVPs. 
   The Encrypted-Data AVP in the Kerberos-Data AVP would carry the
   KRB_PRIV message. 

   DIAMETER proxies SHOULD not modify the Kerberos-Data AVP and the
   Kerberos-Endtoend-Auth AVP since this AVP is meant for DIAMETER 
   end servers.

   On reception of the request from the DIAMETER client, the DIAMETER 
   home server would obtain the secret key for the service principal
   from the Kerberos keytab file. The server would extract the 
   KRB_AP_REQ message from the Kerberos-EndtoEnd-Auth AVP and decrypt 
   the enclosed Kerberos ticket using its secret key and obtain the 
   Kerberos session key. 

   This Kerberos session key is the same as the client session key. 
   The server would then decrypt the Kerberos authenticator using the 
   Kerberos session key and verify authenticator. This completes the 
   Kerberos service authentication.  In case of an error in Kerberos 
   authentication, an Access-Reject is sent with a 
   Kerberos-Endtoend-Auth AVP containing the KRB_ERROR message in the 
   Kerberos authentication TLV. 
 
   On successful Kerberos authentication , the server would extract 
   the KRB_PRIV message from the Encrypted-Data AVP in the 
   Kerberos-Data AVP and decrypt the DIAMETER AVPS from the 
   KRB_PRIV message using the Kerberos session key. The DIAMETER
   server would extract the KRB_SAFE message from the Digest AVP in
   the Kerberos-Data AVP and verify the integrity checksum by 
   generating a checksum over the Command-Code and Identifier fields 
   in the DIAMETER header and any Protected DIAMETER AVPs. 



Kaushik                    expires September 2001               [Page 7]

Internet-Draft                                             February 2001



   
   Sucessful verification of the checksum completes the Kerberos 
   operations on the DIAMETER packet. The homeserver would have 
   successfully performed Kerberos authentication, 
   decryption (optional) and integrity check on the DIAMETER packet.
   The DIAMETER packet can then be processed normally.
                                                                   
   In responding to the request DIAMETER server forms a KRB_AP_REP 
   message containing the Kerberos Response Authenticator. The 
   KRB_AP_REP message is included within the Kerberos-Endtoend-Auth 
   AVP. The KRB_SAFE and KRB_PRIV messages are generated in much the 
   same way as the DIAMETER client. 

   On receiving  the reply from the home server, the DIAMETER client
   would perform the same set of operations as the homeserver to 
   perform end-to-end Kerberos authentication, decryption (optional) 
   and integrity verification. Upon successful Kerberos operation the 
   reply would processed normally.

   The following is an example of a message that includes end-to-end
   security using Kerberos:

      <DIAMETER Msg> ::= <DIAMETER Header, Command-Code = foobar>
                         [<Additional AVPs>]
                         <Kerberos-Endtoend-Auth AVP>
                         <Kerberos-Data AVP>
                         [<Integrity-Check-Value AVP>
                          <Encrypted-Payload AVP>]
                           


5.2 Hop by Hop Security using Kerberos

   Kerberos can be used for DIAMETER hop by hop strong security. 
   Kerberos session keys generated by the Kerberos key exchange 
   between adjecent hop DIAMETER peers SHOULD be used to generate 
   the Encrypted-Payload and Integrity-Check-Value AVPs. The 
   Kerberos-Hopbyhop-Auth AVP WOULD carry the Kerberos 
   authentication messages (KRB_AP_REQ/KRB_AP_REP).

  
   The following is an example of a message that includes hop-by-hop
   and end-to-end security using Kerberos:

      <DIAMETER Msg> ::= <DIAMETER Header, Command-Code = foobar>
                         [<Additional AVPs>]
                         <Kerberos-Hopbyhop-Auth AVP>
                         <Integrity-Check-Value AVP>
                         <Encrypted-Payload AVP>
                         <Kerberos-Endtoend-Auth AVP>
                         <Kerberos-Data AVP>



Kaushik                    expires September 2001               [Page 8]

Internet-Draft                                             February 2001




5.3 Kerberos-EndtoEnd AVP

   The Kerberos-EndtoEnd AVP (AVP Code 320) is of type Grouped 
   and contains the AVPs which are required for End to End 
   security. 

   The grammar for the grouped Data field is defined is:

   Kerberos-EndtoEnd  =  Kerberos-Auth Digest ptextlen Encrypted-Data 
     Digest          = ; KRB_SAFE message containing the integrity 
                         protected AVPs.
     ptextlen        = ; Plaintext-Data-Length.
     Encrypted-Data  = ; KRB_PRIV message containing the encrypted AVPs

      +---------------------------------------------------------------+
      |                 AVP Header (AVP Code = 320)                   |
      +---------------------------------------------------------------+
      |                          Digest AVP                           |
      +---------------------------------------------------------------+
      |                   Plaintext-Data-Length AVP                   |
      +---------------------------------------------------------------+
      |                      Encrypted-Data AVP                       |
      +---------------------------------------------------------------+



5.4 Kerberos-Endtoend-Auth AVP

   The Kerberos-EndtoEnd-Auth AVP (AVP Code = 322) is of type 
   OctetString. This AVP contains the KRB_AP_REQ and KRB_AP_REP, 
   KRB_ERROR messages which are used to create the end-to-end 
   kerberos security association. These messages are used for 
   Kerberos mutual authentication and symmetric key exchange. 
   This AVP WOULD be present only in the first DIAMETER Request
   and Reply messages at the start of a DIAMETER session.

5.5 Kerberos-Hopbyhop-Auth AVP

   The Kerberos-Hopbyhop-Auth AVP (AVP Code = 322) is of type 
   OctetString. This AVP contains the KRB_AP_REQ and KRB_AP_REP,
   KRB_ERROR messages which are used to create kerberos security 
   associations across adjecent DIAMETER hops. These messages are 
   used for Kerberos mutual authentication and symmetric key 
   exchange. This AVP WOULD be present only in the first DIAMETER 
   Request and Reply messages at the start of a DIAMETER session.




Kaushik                    expires September 2001               [Page 9]

Internet-Draft                                             February 2001



5.6  Authentication-Transform-Id AVP


   Additional value added to the Authentication-Transform-Id which
   carried as part of the Integrity-Checksum-Value AVP to specify
   all authentication transforms supported by Kerberos.

   Kerberos                2


5.7  Encryption-Transform-Id AVP


   Additional value added to the Encryption-Transform-Id which
   carried as part of the Encrypted-Payload AVP to specify
   all encryption transforms supported by Kerberos.

   Kerberos                   2 


6.0  IANA Considerations

   The Packet Type Codes, Attribute Types, and Attribute Values defined
   in this document are registered by the Internet Assigned Numbers
   Authority (IANA) from the DIAMETER name spaces.

7.0  Security Considerations
  
   This draft determines whether to use Kerberos purely on the basis of 
   the existence or non-existence of a Kerberos service principal. This 
   presents an opportunity for a downgrade attack wherein because an 
   attacker can spoof an error message from the KDC and make the 
   DIAMETER client not use end to end security which would compromise 
   end to end security. Implementations should provide users with a 
   policy knob which would prevent DIAMETER clients from using only
   hop-by-hop security in case they encounter an error while acquiring 
   the service principal ticket from the KDC.


8.0 References

   [1]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base
        Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
        September 2000.

   [2]  Kohl, J., and C. Neuman, "The Kerberos Network Authentication 
        Service (V5)", RFC 1510, September 1993.

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



Kaushik                    expires September 2001              [Page 10]

Internet-Draft                                             February 2001




   [4]  M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
        Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work
        in progress, June 2000.

   [5]  T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA",
        draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep-
        tember 2000.

   [6]  S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
        Authorization, and Accounting Requirements", draft-ietf-
        mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000.

   [7]  Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public
        Key Infrastructure Online Certificate Status Protocol (OCSP)",
        RFC 2560, June 1999.

   [8]  Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC
        2477, January 1999.

   [9]  P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft-
        calhoun-diameter-nasreq-05.txt, IETF work in progress, September
        2000.

   [10] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft-
        calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
        tember 2000.

   [11] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension",
        draft-calhoun-diameter-accounting-08.txt, IETF work in progress,

  



10.0 Author's Address

   Kaushik Narayan
   HCL-Cisco Offshore Development Centre,
   49-50, Nelson Manickam Road,
   Chennai, Tamilnadu 600 029
   India

   EMail: kaushik@cisco.com
   Phone: +091-44-3741939




Kaushik                    expires September 2001               [Page 1]

Internet-Draft                                             February 2001



11.0  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."




Kaushik                    expires September 2001              [Page 11]

Internet-Draft                                             February 2001