Internet DRAFT - draft-forsberg-pana-secure-network-access-auth
draft-forsberg-pana-secure-network-access-auth
Internet Engineering Task Force Dan Forsberg
Internet Draft Jarno Rajahalme
draft-forsberg-pana-secure-network-access-auth-00.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]
