One document matched: draft-polk-slp-loc-auth-server-00.txt

Internet Draft					  James M. Polk
Issued: March 10, 2000				  Cisco Systems
Expiration: September 10, 2000                      Haitao Tang   
					                  Nokia

   
   
   
   

   
        Spatial Location Protocol Location Server 
                     Authentication    
   	<draft-polk-slp-loc-auth-server-00.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 Engi-
neering 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. 


Conventions used in this document

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



Polk         draft-polk-slp-loc-auth-server-00.txt       Page 1

Internet Draft   Spatial Location Server Auth        March 2000


Abstract 
    
This document describes the early considerations for a Spatial 
Location Server and issues that will need to be addressed when
an IP Device that has determined its location (TBD in another 
document effort) requests, or is requested, to provide that
information to a Spatial Location Server (SLS).

Table of Contents 
     
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2  
Table of Contents. . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Mechanisms of the Spatial Location Server. . . . . . . . 2
3.0 IANA Considerations  . . . . . . . . . . . . . . . . . . 4
4.0 Security Considerations. . . . . . . . . . . . . . . . . 4
5.0 References . . . . . . . . . . . . . . . . . . . . . . . 4
6.0 Acknowledgments  . . . . . . . . . . . . . . . . . . . . 4
7.0 Author Information . . . . . . . . . . . . . . . . . . . 5

1.0 Introduction

This document describes the early considerations for a Spatial 
Location Server and issues that will need to be addressed when
an IP Device that has determined its location (TBD in another 
document effort) and requests, or is requested, to provide that
information to a Spatial Location Server (SLS).


2.0 Mechanisms of the Spatial Location Server

First and foremost, each Spatial Location Server (SLS) will 
MUST determine its own location. This location discovery 
and determination will be performed in a manner outlined/
stipulated in the definitions of the Spatial Location Protocol 
(SLP) itself; which is covered by another I-D within this BOF.

It appears likely a need for an Authentication Server, similar 
to a Security Server, that should be within the Network Domain 
of a SLP Location Server in order to validate its existence 
within that Domain. From this Authentication Server Concept, a
Hierarchy can be obtained for authenticating to the next higher
authority in a similar manner as a Certificate Authority Server
scenario. This communications with either hierarchically 
parallel SLS servers for the purposes of back-up/fail-over, or 
up and down the overall hierarchy should be done utilizing 
IPsec [1]. Whether this is done with ESP [2] or AH [3] is up 
to the BOF to determine. Additionally, investigation should be

Polk         draft-polk-slp-loc-auth-server-00.txt       Page 2

Internet Draft   Spatial Location Server Auth        March 2000


made into GLP [4] from the MMUSIC WG for similarities or 
possible slight modifications to that protocol which could 
allow its application here for this purpose; although other 
solutions/protocols providing this desired result should be 
mentioned to the authors of this document (who happen to be the
chairs of this BOF) for investigation within the BOF.

Once a domain has an SLS authenticated by its higher authority, 
it can establish boundaries either dynamically (not yet covered 
by this document or other I-D/RFC) or via manual configuration 
from its domain administrator. These boundaries will be repre-
sented by the BOF/WG agreed upon coordinate Legend for SLP.

The following is an early potential list, in no particular order 
and easily a subset of the possibilities, of coordinate mecha-
nisms/values, where reference accuracy and valid time must 
associated:

      * X, Y, Z
      * Long., Lat., Alt.
      * Planet, Country, State/Province, City/town, street, 
        building, zip code, floor, quadrant of floor, office/
        cube number
      * To geographic area like a floor, part of a floor, a 
        building a city ()
 
Known additional or replacement identification information could 
include:

      * Relation to directly attached L2 Switch/Router
      * Relative or absolute location to any of the above items
      * Perhaps a remote site relative to a corporate site
      * Residence or company name

As a new IP device comes on-line within a domain that either 
has, or mandates, SLP, it will (likely) determine if an SLS 
exists via DNS query. A 'yet-to-be-decided' method of authenti-
cation of the Server from the new IP device's point of view 
should be required. If successful, it should then either trans-
mit or reply, respectively, its location based on the performed 
function of SLP to that SLS server. Again, with a 'yet-to-be-
decided' method of authentication should be performed, this 
time from the server's point of view that this is a via IP 
device for this domain.




Polk         draft-polk-slp-loc-auth-server-00.txt       Page 3

Internet Draft   Spatial Location Server Auth        March 2000


3.0 IANA Considerations

The authors don't believe there are any within this document at
this time.

4.0 Security Considerations

There is a possibility of misuse of this protocol. This truly 
has the potential of a "Big-Brother" scenario. If a malicious 
attack occurred to the SLS, all IP devices within that domain 
would have their (as best as SLP can deduce) location discovered
for whatever publication or distribution that individual wanted.

Highly sensitive areas such as research facilities and govern-
ment agencies should have a paranoid security view of this 
protocol's misuse. Yet, in many ways, the benefits of appli-
catons such as e911 could outweigh the potential dangers of 
its possible misuse. Though, methods to prevent or avoid the 
possible misuses should be considered. The privacy issues and
their related usability issues should also be investigated. 
The authors think these are a part of the crucial requirements
for the spatial location effort.  

5.0 References:

[1] RFC2401 "Security Architecture for the Internet Protocol" 
    S. Kent and Ran Atkinson, November 1998

[2] RFC2406 "IP Encapsulating Security Payload (ESP)" S. Kent 
    and Ran Atkinson, November 1998

[3] RFC2402 "IP Authentication Header (AH)" S. Kent and Ran 
    Atkinson, November 1998

[4] Internet Draft "draft-ietf-iptel-gwloc-framework-06.txt"
    J.Rosenberg, H.Schulzrinne November 29, 1999 "work-in-
    progress"


6.0 Acknowledgments

The authors would like to thank Rohan Mahy who made comments 
and suggestions contributing to this document.





Polk         draft-polk-slp-loc-auth-server-00.txt       Page 4

Internet Draft   Spatial Location Server Auth        March 2000



7.0 Author Information

James M. Polk
Cisco Systems
18581 N. Dallas Parkway, Suite 100
Dallas, TX 75287, US
jmpolk@cisco.com

Haitao Tang
Nokia Research Center
Itamerenkatu 11-13
FIN-00180, Helsinki, Finland
haitao.tang@nokia.com 

"Copyright (C) The Internet Society (date). 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 organi-
zations, 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."

The Expiration date for this Internet Draft is:

September 10, 2000 

Polk         draft-polk-slp-loc-auth-server-00.txt       Page 5

Internet Draft   Spatial Location Server Auth        March 2000