[Ietf-not43] First draft on Relay bags in FIRS
Peter Gietz
Peter.Gietz at daasi.de
Wed Aug 13 16:37:56 EDT 2003
Hi all,
please find attached a first version of the promissed Draft on FIRS
Relay Bag.
As you can see in the todo section, there is still a little work to do,
which I can finalize after your comments on the document.
I would also be interested in editorial comments, e.g. to improve the
English. Such comments could be sent to me directly.
Cheers,
Peter
--
_______________________________________________________________________
Peter Gietz (CEO)
DAASI International GmbH phone: +49 7071 2970336
Wilhelmstr. 106 Fax: +49 7071 295114
D-72074 Tübingen email: peter.gietz at daasi.de
Germany Web: www.daasi.de
Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
-------------- next part --------------
Network Working Group P. Gietz
Internet-Draft DAASI International GmbH
Expires: February 11, 2004 August 13, 2003
Relay Bag Search Control for the Federated Internet Registry Service
draft-ietf-crisp-firs-relay-00
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.
This Internet-Draft will expire on February 11, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes an LDAP control to allow additional
unspecified data to be returned with a referral to the client, which
can submit these data to the referred to server in support of the
Federated Internet Registry Service (FIRS) described in [FIRS-ARCH]
and [FIRS-CORE]. A flexible container called Relay Bag as required
in [CRISP-REQ] is included into this extension to the LDAP search
operation.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Gietz Expires February 11, 2004 [Page 1]
Internet-Draft Relay Bag August 2003
document are to be interpreted as described in [RFC2119].
1. Background and Intent of use
The Federated Internet Registry Service (FIRS) described in [FIRS-
ARCH] and [FIRS-CORE] is a distributed service for storing, locating
and transferring information about the Internet Resources using
LDAPv3 [RFC3377]. It is thus an implementation of a Cross Registry
Information Service Protocol as specified in the requirements
document [CRISP-REQ]. To completly fulfil these requirements, a
feature called Relay Bag has to be supported.
A Relay Bag is a flexible container which may contain unspecified
data that a server can give back to a client in addition to a
referral. The data are not to be read and understood by the client,
but to be forwarded by the client to the referred to server. The
data transported in the Relay Bag are thus server operator-to-
operator coordination data, e.g. for auditing or tracking.
This document specifies such a Relay Bag with the means of an LDAP
control extenting the LDAP search operation. Basically an LDAP
control consists of a controlType, containing the OID for the
control, a boolean field for marking the criticality of the control,
and an optional controlValue containing arbitrary data with octet
string syntax.
2. Relay Bag Search Request and Response control
The Relay Bag control is included in the SearchRequest and in the
SearchResultReference message as part of the controls field of
LDAPMessage, as defined in section 4.1.12 of [RFC2251]. It MUST NOT
be included in any other request or result message.
Since the control syntax is the same in request and response, the
following controlType is used in both cases:
relayBagSearchOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.10126.1.15.7.1
The controlValue is a BER-encoded Octet string, which can contain any
kind of data:
relayBagValue ::== OCTET STRING
The criticality MUST be set to TRUE.
Gietz Expires February 11, 2004 [Page 2]
Internet-Draft Relay Bag August 2003
3. Operation Requirements
A FIRS client SHOULD evaluate if the server it initially connects to
supports this feature, by checking if the controlType Object
Identifier of the control specified in this document
(relayBagSearchOID) is stored in the attribute supportedControl of
the root DSE entry, which is specified in [RFC2251], section 3.4.
If the server supports this control the Client MUST use it when
sending a search request to the server. The control MUST always be
marked as critical when used. In the initial server contact the
controlValue sent by the client SHOULD be empty.
When the server sends back the search response, it MUST include the
control identified by the controlType field. The controlValue SHOULD
contain data that at least give the information that the server had
referred the client to another server. The semantics for such
information is not defined in this document and is to be specified by
the service operators. The semantics could include a mechanism to
make sure that the data have not been changed, e.g. by digitally
signing a hash value of the contents.
When the client follows the referral and sends its search request to
the referred to server, it MUST again check if the referred to server
supports the Relay Bag control. If so, the client MUST use the
control and send the data given by the referring server in the
controlValue field unchanged in the controlValue field of the search
request.
Servers that support this control MAY decide to only serve clients
that support and use this control. If a server wants to thus enforce
the control, every search request without this control SHOULD be
responded to with the resultCode unwillingToPerform (53).
4. Relationship to other search controls
The Relay Bag Search Control SHOULD NOT be used together with any
other existing search controls. If a new search control is to be
used in combination with the Relay Bag Search Control the document,
describing that new search control has to deal with possible
implications.
5. Security considerations
The Relay Bag Search Control can be used in services to provide data
only to clients that have properly authenticated to one server, by
passing over the authentication status of the client to the referred
to server.
Gietz Expires February 11, 2004 [Page 3]
Internet-Draft Relay Bag August 2003
To make sure the client has not changed the contents of the Relay
Bag, it is possible to use the PKI feature of digitally signing the
contents of the Relay Bag, e.g. by using X.509 based PKI with
certificates as specified in [RFC3280].
Obviously any usage of this search control is dependant on the
services that use it, since this document does not specify and
enforce any semantics of the controlValue field. Thus every service,
using this control has to be aware of the possible security
implications.
6. IANA considerations
TBD
7. Open issues
There are still a number of todos with respect to this draft.
Following work items will be dealt with in the next version of this
draft:
o re-evaluate the MUST, SHOUD and MAY with respect to the
requirements specified in [CRISP-REQ], especially with respect to
the criticality of the control
o Section on IANA considerations
o proofread
8. Acknowledgments
This document is the result of discussions taking place in the IETF
CRISP WG. The concept of Relay Bags is derived from that activity.
This document has been written in XML according to the DTD specified
in RFC2629. xml2rfc has been used to generate an RFC2033 compliant
plain text form. The XML source and a HTML version are available on
request.
9. References
Normative references
[CRISP-REQ] Newton, A., "Cross Registry Internet Service Protocol
(CRISP) Requirements", May 2003, <draft-ietf-crisp-
requirements-05.txt>.
Gietz Expires February 11, 2004 [Page 4]
Internet-Draft Relay Bag August 2003
[FIRS-ARCH] Hall, E., "The Federated Internet Registry Service:
Architecture and Implementation Guide", May 2003,
<draft-ietf-crisp-firs-arch-01.txt>.
[FIRS-CORE] Hall, E., "The Federated Internet Registry Service: Core
Elements", May 2003, <draft-ietf-crisp-firs-core-
01.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377] Hodges, J. and RL. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
Non-normative references
[RFC3280] Housley, R., Polk, T., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 3280, April 2002.
Author's Address
Peter Gietz
DAASI International GmbH
Wilhelmstr. 106
Tuebingen 72074
DE
Phone: +49 7071 29 70336
EMail: peter.gietz at daasi.de
URI: http://www.daasi.de/
Gietz Expires February 11, 2004 [Page 5]
Internet-Draft Relay Bag August 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gietz Expires February 11, 2004 [Page 6]
More information about the Ietf-not43
mailing list