Internet Engineering Task Force Dan Forsberg Internet Draft Jarno Rajahalme draft-forsberg-pana-secure-network-access-auth-01.txt Nokia Expires: March 2003 September 2002 Secure Network Access Authentication (SeNAA) <draft-forsberg-pana-secure-network-access-auth-01.txt> 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft describes how reliable Secure Network Access Authentication (SeNAA) protocol over UDP carries Transport Layer Security (TLS) protocol. SeNAA messages are formatted like Diameter messages and contain Attribute Value Pairs (AVPs) that are protected with TLS Record Layer. SeNAA provides secure transport for Extensible Authentication Protocol (EAP) between PANA Client (PaC) and PANA Authentication Agent (PAA). PANA stands for Protocol for carrying Authentication for Network Access. Forsberg, Rajahalme Expires March 2003 [Page 1]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 Table of contents 1.0 Introduction 2.0 Terminology 3.0 Protocol overview 3.1 SeNAA 3.2 PAA location 3.3 Reliable request and response style transactions 3.4 Re-authentication 3.5 Disconnect indication 3.6 Error handling with TLS 4.0 Message formats 4.1 Server-Certificate-Request (SCR) 4.2 Server-Certificate-Answer (SCA) 4.3 Client-Security-Association-Request (CSAR) 4.4 Client-Security-Association-Answer (CSAA) 4.5 AAA-Client-Request (CLR) 4.6 AAA-Client-Answer (CLA) 4.7 SeNAA-Session-Termination-Request (SSTR) 4.8 SeNAA-Session-Termination-Answer (SSTA) 4.9 SeNAA-Abort-Session-Request (SASR) 4.10 SeNAA-Abort-Session-Answer (SASA) 5.0 AVP formats 5.1 TLS-Payload AVP 5.2 Msg-Checksum AVP 5.3 Device-Identifier AVP 6.0 Message re-transmission timers 7.0 Security Considerations 8.0 IANA Considerations 9.0 References 10.0 Full Copyright Statement 11.0 Acknowledgments 12.0 Authors' addresses Forsberg, Rajahalme Expires March 2003 [Page 2]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 1.0 Introduction Terminal's network access authentication in different network technologies has become an important issue in the Internet. Different authentication methods already exist but are more or less link layer dependent. Mobile terminals utilize different link layer technologies and roam between them. Generic link layer independent authentication and authorization method is needed to support smooth interaction between mobile terminals and access networks while roaming. A link layer agnostic solution for network access authentication is proposed. This draft describes how reliable Secure Network Access Authentication (SeNAA) protocol over UDP carries Transport Layer Security (TLS) protocol. SeNAA messages are formatted like Diameter messages and contain AVPs that are protected with TLS Record Layer. SeNAA provides secure transport for EAP between PANA Client (PaC) and PANA Authentication Agent (PAA). 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 [RFC 2119]. 2.0 Terminology This document uses the same terminology as has been described in PANA requirements draft [PANAREQ]. Additionally the following terms are used. SeNAA Secure Network Access Authentication 3.0 Protocol overview SeNAA uses UDP [UDP] as the transport protocol. UDP is lightweight and allows application level implementations with port numbers. UDP carries Diameter [DIAM] formatted SeNAA messages. SeNAA provides reliable request and response style message delivery (re-transmission and duplicate packet detection). SeNAA does not assume a secure channel between PaC and PAA. Thus, on top of SeNAA protocol Transport Layer Security [TLS] protocol is used to negotiate a Local Security Association (LSA) between PaC and PAA. TLS provides authentication, privacy, integrity, and replay protection. It is used to protect SeNAA message AVPs and EAP [EAP] between PaC and PAA. AVPs that need protection are fed to the TLS Record layer and the resulting encrypted and compressed data is stored into a TLS-Payload AVP. EAP protocol is carried inside an EAP- Forsberg, Rajahalme Expires March 2003 [Page 3]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 Payload AVP [NASREQ]. SeNAA messages after succesfull TLS handshake are integrity protected with a checksum stored in the Msg-Checksum AVP. The AVP is protected with TLS Record layer. TLS is also used for re-authentication between PaC and PAA. TLS supports mutual authentication and can optionally be used instead of EAP for user authentication. In all cases TLS is used for access network authentication. SeNAA messages carry information such as the PaC's Device Identifier (DI), that MUST be integrity protected [PANAREQ]. If PAA supports DIAMETER and/or RADIUS AAA back-end, signaling between PaC and PAA can easily be extended to the back-end. SeNAA is designed in such a way that the TLS protocol can be left out from the protocol stack. SeNAA messages can be carried over UDP without AVP encryption if the PaC and PAA already share an adequate secure channel (i.e. L2 encryption and authentication). SeNAA doesn't rely on any modifications to the EAP protocol. It provides secure transport up to the PAA for EAP. Thus, any existing EAP methods can be used securely with SeNAA between PaC and PAA. Security after PAA is out of scope of SeNAA. PAA is assumed to get user authentication answer (Success or Failure) from the authenticator. SeNAA utilizes protocols like EAP, TLS, UDP and IP that are assumed to exist in the PaC terminal already even without SeNAA. Diameter like message formatting and request/response style reliability transport is one additional requirement for the PaC terminal and is provided with SeNAA protocol. TCP [TCP] and SCTP [SCTP] are considered too heavy weight transport protocols for SeNAA purposes (i.e. more message round trips needed). +-----------+ | EAP | |-----------| | SeNAA/TLS | |-----------| | UDP | |-----------| | IP | +-----------+ Figure 1. SeNAA Protocol stack in PaC Data protection, such as IP datagrams, is out of the scope of SeNAA. One possibility for further studies is to use the key material produced in the TLS handshake process with IPSec [IPSEC]. Forsberg, Rajahalme Expires March 2003 [Page 4]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 3.1 SeNAA Successful mutual authentication is divided into two phases. In phase 1 the network is authenticated and the user in phase 2. Phase 1 consists of a TLS handshake as is shown in Figure 2a. Local re-authentication, where PaC authenticates to PAA, belongs to the phase 1 and is handled with TLS Session Resumption (Figure 2b). Access network authentication is based on access network certificates. How certificates are created, processed and verified is out of the scope of this document. Phase 2 uses EAP for authenticating the user (Figure 3). User authentication is bound to the DI, which is used to control access to the network. PaC PAA --- --- | | | SCR{ | | User-Name, | | TLS-Payload{ | | TLS{ | | Client Hello | | } | | } | | } | |--------------------------------->>| | | | | | SCA{ | | Session-Id, | | TLS-Payload{ | | TLS{ | | Server Hello, | | Server Cert., | | Server Key Exch., | | (Certificate req.), | | Server Hello done | | } | | } | | } | |<<---------------------------------| +--------------------+ | | verify certificate | | +--------------------+ | | | | CSAR{ | Forsberg, Rajahalme Expires March 2003 [Page 5]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 | Session-Id, | | TLS-Payload{ | | TLS{ | | (Client Cert.), | | (Certificate ver.), | | Client Key Exch. | | Change cipher spec., | | Client Finished | | } | | } | | } | |--------------------------------->>| | | | | | CSAA{ | | Session-Id, | | TLS-Payload{ | | TLS{ | | Change cipher spec., | | Server Finished | | } | | } | |<<---------------------------------| | | Figure 2a. Phase 1: Initial authentication with TLS. In phase 1, Server-Certificate-Request (SCR) message carries Client- Hello TLS message. Server-Certificate-Answer (SCA) carries the TLS answer which contains the Access Network certificate. PaC verifies the certificate. PAA also adds a Session-Id AVP into the SCA message. This Session-Id is different from the TLS session-Id. The next messages MUST have this AVP included during the whole session. To finish the TLS handshake PaC sends Client-Security-Association- Request (CSAR) message to the PAA. PAA answers with Client-Security- Association-Answer (CSAA). PaC PAA --- --- | | | CSAR{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | TLS{ | | Client Hello | | } | | } | Forsberg, Rajahalme Expires March 2003 [Page 6]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 | } | |--------------------------------->>| | | | | | CSAA{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | TLS{ | | Server Hello, | | Change cipher spec., | | Server finished | | } | | } | | } | |<<---------------------------------| | | | | | CSAR{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | TLS{ | | Change cipher spec., | | Client finished | | } | | } | | } | |--------------------------------->>| | | | | | CSAA{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | Result-Code | | } | | } | |<<---------------------------------| | | Figure 2b. Phase 1: Re-authentication with TLS. When TLS is not used, a different UDP port number (PAA UDP port <UDP- port3>, PaC UDP port <UDP-port4>) MUST be used for plaintext CLR/CLA message delivery. PaC can decide not to use phase 1 authentication but MUST use phase 1 authentication if <UDP-port3> is not reachable. Similarly if UDP port <UDP-port1> is not reachable, PaC SHOULD try to Forsberg, Rajahalme Expires March 2003 [Page 7]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 use UDP port <UDP-port3>. In phase 2, after a successful TLS handshake, PaC uses AAA-Client- Request (CLR) message to start user authentication and DI authorization. CLR carries EAP-Payload AVP to PAA. PAA answers with AAA-Client-Answer (CLA) message with a Result-Code AVP [DIAM]. Result-Code informs PaC if multiple round trips are needed (DIAMETER_MULTI_ROUND_AUTH) for completing the EAP authentication method (DIAMETER_SUCCESS) or if the authentication (authorization) succeeded or failed (DIAMETER_AUTHENTICATION_REJECTED) [DIAM]. PaC adds it's DI(s) into the CLR message so that PAA can verify the integrity of the DI and optionally provide it for the enforcement point. PaC PAA --- --- | | | | | CLR{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | User-Name, | | Device-Identifier, | | EAP-Payload, | | Authorization-Lifetime | | } | | } | |--------------------------------->>| | | | | | CLA{ | | Session-Id, | | TLS-Payload{ | | Msg-Checksum, | | Result-Code, | | EAP-payload, | | Authorization-Lifetime, | | Auth-Grace-Period, | | Multi-Round-Time-Out | | } | | } | |<<---------------------------------| | | . . . . | CLR | Forsberg, Rajahalme Expires March 2003 [Page 8]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 |--------------------------------->>| | | | CLA | |<<---------------------------------| | | Figure 3. Phase 2: User authentication signaling. EAP is carried inside EAP-Payload AVP. 3.2 PAA location and discovery PAA can be co-located in the AR or separated from the ARs. In case of separation, ARs act as relay agents to PAA for MN. PAA is in the same subnet as the AR and MN. When PAA receives a message from MN through an AR, it MUST send the reply directly to the MN. When PAA is separated from ARs, an AR SHOULD relay MN's SeNAA messages to the PAA. When MN receives an answer from PAA, it MUST send further requests to the PAA directly. 3.3 Reliable request and response style transactions SeNAA uses request and response style transactions. For each request a response is sent. If response is not received in time, the request is re-sent. This mechanism is used for packet loss recovery. The received response works as an acknowledgment. SeNAA uses Diameter message formatting. The Diameter message header provides packet duplication (End-to-End Id) detection and request/response mapping (Hop-by-Hop Id). To protect integrity of the Diameter header and the parts that are not protected with TLS, a MAC is calculated over the Diameter message. The MAC is put into an AVP called Msg-Checksum. 3.4 Re-authentication PaC needs to be authenticated before network access is granted through the enforcement point (EP) in the access network. Authentication and re-authentication initiator can be PaC or PAA. PaC starts re-authentication by sending CSAR message with TLS Client Hello in the TLS-Payload AVP to PAA to UDP port <UDP-port1> (Figure 2b). Similarly, PAA initiates re-authentication by sending CSAA message with TLS Server Hello message in the TLS-Payload AVP to PaC to UDP port <UDP-port2>. The hello message contains the current TLS session specific id, which is used to detect session resumption from initial authentication [TLS]. Re-authentication involves multiple CSAR/CSAA round trips. Forsberg, Rajahalme Expires March 2003 [Page 9]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 After TLS handshake or session resumption is done and the SA is established PaC uses the TLS Record Layer to encrypt SeNAA message AVPs. 3.5 Disconnect indication and session termination SeNAA doesn't assume connection-oriented links [PANAREQ]. Thus, TLS re-authentication is used for notifying PAA of PaC's presence. Re- authentication interval is implementation specific <TBD?>. PaC can explicitly terminate a session with SeNAA-Session- Termination-Request message (SSTR) sent to PAA. PAA answers with a SeNAA-Session-Termination-Answer. DIAMETER_LOGOUT [DIAM] is used in the Termination-Cause AVP in the SSTR message. The Result-Code value in SSTA is DIAMETER_SUCCESS [DIAM]if session was succesfully terminated or DIAMETER_UNKNOWN_SESSION_ID [DIAM], if session was not found. PaC PAA --- --- | | | SSTR{ | | Session-Id, | | TLS-Payload{ | | Termination-Cause, | | TLS{ | | Close_notify_alert | | } | | } | | } | |--------------------------------->>| | | | | | SSTA{ | | Session-Id, | | TLS-Payload{ | | Result-Code, | | TLS{ | | close_notify_alert | | } | | } | | } | |<<---------------------------------| | | Figure 4. Session termination from PaC to PAA Forsberg, Rajahalme Expires March 2003 [Page 10]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 PAA can also terminate the session with SeNAA-Abort-Session-Request (SASR). PaC answers with SeNAA-Abort-Session-Answer (SASA). Termination-Cause AVP contains DIAMETER_ADMINISTRATIVE, if the session was terminated due to the administrative reasons [DIAM], DIAMETER_SESSION_TIMEOUT, if the session timeout timer expired [DIAM]. PaC PAA --- --- | | | SASR{ | | Session-Id, | | TLS-Payload{ | | Termination-Cause, | | TLS{ | | close_notify_alert | | } | | } | | } | |<<---------------------------------| | | | SASA{ | | Session-Id, | | TLS-Payload{ | | Result-Code, | | TLS{ | | Close_notify_alert | | } | | } | | } | |--------------------------------->>| | | Figure 5. Session termination from PAA to PaC 3.6 Error handling with TLS TLS Alert, Handshake and Change cipher spec. protocols are carried inside TLS Record Layer. For example if TLS Alert protocol reports a fatal error it is delivered with the next TLS-Payload AVP or with separate CSAR/CSAA messages. The SeNAA application MUST understand the return codes from TLS Record Layer API functions. When fatal error is received, the TLS session is torn down. The SeNAA session MUST be re-negotiated. Forsberg, Rajahalme Expires March 2003 [Page 11]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 4.0 Message Formats TLS message formats can be found from [TLS]. [DIAM] explains Diameter message header format and AVP format. This document also uses the ABNF notation for Diameter message format descriptions [DIAM]. SCA and CSAA message don't contain Result-Code AVPs. 4.1 Server-Certificate-Request (SCR) Format of the SCR message: < Server-Certificate-Request > ::= < Diameter Header: <TBD>, REQ, PXY > { User-Name } { TLS-payload } TLS-Payload AVP contains the TLS handshake messages in the AVP data area as specified in [TLS]. The TLS-Payload AVP contains TLS-Client- hello. 4.2 Server-Certificate-Answer (SCA) Format of the SCA message: < Server-Certificate-Answer > ::= < Diameter Header: <TBD>, PXY > < Session-Id > { TLS-payload } A Session-Id is generated for the PaC and delivered in the Session-Id AVP. The TLS-Payload AVP contains TLS Server-hello, TLS Server- Certificate, TLS server-Key-Exchange, and TLS Server-Hello-Done messages. 4.3 Client-Security-Association-Request (CSAR) Format of the CSAR message: < Client-Security-Association-Request > ::= < Diameter Header: <TBD>, REQ > < Session-Id > { TLS-payload } The Session-Id AVP is used in every SeNAA message between PaC and PAA. The TLS-Payload contains TLS-Client-Key-Exchange, TLS-Change-Cipher- Forsberg, Rajahalme Expires March 2003 [Page 12]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 Spec, and TLS-Client-Finished messages. 4.4 Client-Security-Association-Answer (CSAA) Format of the CSAA message: < Client-Security-Association-Answer > ::= < Diameter Header: <TBD>, PXY > < Session-Id > { TLS-Payload } The TLS-Payload contains TLS-Change-Cipher-Spec and TLS-Server- Finished messages. 4.5 AAA-Client-Request (CLR) Format of the initial CLR message: < AAA-Client-Request > ::= < Diameter Header: <TBD>, REQ, PXY > < Session-Id > [ TLS-Payload: { Msg-Checksum } { User-Name } { Device-Identifier } [ EAP-Payload ] [ Authorization-Lifetime ] ] The TLS-Payload AVP data area contains encrypted AVPs through TLS Record layer. 4.6 AAA-Client-Answer (CLA) Format of the CLA message from PAA to PaC: < AAA-Client-Answer > ::= < Diameter Header: <TBD>, PXY > < Session-Id > [ TLS-Payload: { Msg-Checksum } { Result-Code } [ EAP-payload ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Multi-Round-Time-Out ] ] The TLS-Payload AVP data area contains encrypted AVPs through TLS Record layer. Forsberg, Rajahalme Expires March 2003 [Page 13]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 4.7 SeNAA-Session-Termination-Request (SSTR) < SeNAA-Session-Termination-Request > ::= < Diameter Header: 275, REQ,PXY > < Session-Id > [ TLS-Payload: [ Msg-Checksum ] { Termination-Cause } ] 4.8 SeNAA-Session-Termination-Answer (SSTA) < SeNAA-Session-Termination-Answer > ::= < Diameter Header: 275, REQ,PXY > < Session-Id > [ TLS-Payload: [ Msg-Checksum ] { Result-Code } ] 4.9 SeNAA-Abort-Session-Request (SASR) 4.10 SeNAA-Abort-Session-Answer (SASA) 5.0 AVP Formats This section defines used AVPs that are not defined in [DIAM]. 5.1 TLS-Payload AVP The TLS-Payload AVP data contains encapsulated AVPs that are encrypted and compressed by TLS Record layer. Upon receive of TLS- Payload AVP the data area is first fed to the TLS Record layer to get the plain text AVP list for further processing. 5.2 Msg-Checksum AVP The Msg-Checksum AVP data contains checksum of the Diameter message header and AVPs that are not protected with TLS. The TLS-Payload AVP MUST be the last AVP in the message. This makes it possible to calculate the MAC before creating the TLS-Payload AVP. Checksum algorithm is <TBD>. Forsberg, Rajahalme Expires March 2003 [Page 14]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 5.3 Device-Identifier AVP Device-Identifier AVP may contain one or more device identifiers, for example a layer 2 MAC address and an IPv6 address. Each identifier in the AVP data payload has the format described in Figure 6. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Device-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Figure 6. Device-Identifier format Type is one of the following: <TBD> 6.0 Message re-transmission timers SeNAA provides reliable request and response style transactions. Peer which initiates the transaction is responsible for re-transmission if the corresponding response is not received in <TBD-msec1> milliseconds. Maximum number of retries is <TBD-retries1>. If Multi-Round-Time-Out AVP is included in a SeNAA message from PAA to PaC, the re-transmission (same Hop-by-Hop Id and End-to-End Id) MUST not exceed this time limit. 7.0 Security Considerations If an EAP method is used in an unsecure environment, TLS with SeNAA doesn't provide adequate protection for the man-in-the-middle attack with that EAP method. If TLS is not used, a secure enough link layer MUST be used between PaC and PAA. 8.0 IANA Considerations UDP Port number(s) must be defined. SCR/SCA, CSAR/CSAA and CLR/CLA message command codes must be assigned. Msg-Checksum and TLS-Payload AVP codes must be assigned. 9.0 References Forsberg, Rajahalme Expires March 2003 [Page 15]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP0014, March 1997. [PANAREQ] R. Penno (ed.), A. Yegin, Y. Ohba, G. Tsirtsis, C. Wang. "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", Internet draft <draft-ietf-pana-requirements-04.txt>, April 2003, Work in progress. [UDP] J. Postel, "User Datagram Protocol", RFC768, STD0006, Aug 1980. [EAP] L. Blunk, J. Vollbrecht, Bernard Aboba, "Extensible Authentication Protocol (EAP)", Internet draft <draft-ietf- pppext-rfc2284bis-04.txt>, April 2002, Work in progress. [TLS] T. Dierks, C. Allen., "The TLS Protocol Version 1.0.", RFC2246, January 1999. [DIAM] Pat R. Calhoun, John Loughney, Erik Guttman, Glen Zorn, Jari Arkko, "Diameter Base Protocol", Internet draft, <draft-ietf-aaa-diameter-14.txt>, October 2002, Work in progress. [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Application", IETF work in progress. [TCP] J. Postel, "Transmission Control Protocol.", STD0007, RFC793, Sep 1981. [SCTP] L. Ong, J. Yoakum, "An Introduction to the Stream Control Transmission Protocol (SCTP)." RFC3286, May 2002. [IPSEC] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)." RFC2406, November 1998. 10.0 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Forsberg, Rajahalme Expires March 2003 [Page 16]
INTERNET-DRAFT Secure Network Access Authentication Sep 16, 2002 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. 11.0 Acknowledgments The authors of this document would like to thank N. Asokan for giving security information related to this draft. 12.0 Authors' Addresses Dan Forsberg (Editor) Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland Phone: +358 50 4839470 EMail: dan.forsberg@nokia.com Jarno Rajahalme Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland Phone: +358 50 4839470 EMail: jarno.rajahalme@nokia.com Forsberg, Rajahalme Expires March 2003 [Page 17]