Subject: RE: WG Last Call Status of Requirements Document

From: Christopher Apple <[email-masked]>
Date: Mon, 4 Jun 2001 16:09:09 -0400

Rick Huber pointed out that a clarification was needed
about the term "anonymous replication." What John and I had
in mind when using this term is:

Anonymous Replication - Replication where the endpoints are
			      identified to each other but not
				authenticated.

(To give credit where its due, that's one of a few definitions
 that Rick proposed; this one happens to fit our intent when
 using the term in the original posting.)

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email-masked]> 
(V) 610-425-2860

-----Original Message-----
From: Christopher Apple [mailto:[email-masked]]
Sent: Monday, June 04, 2001 10:35 AM
To: [email-masked]'
Cc: John Strassner (E-mail)
Subject: WG Last Call Status of Requirements Document

LDUPers,

Thanks for the spirited discussion about the requirements draft. Your
co-chairs have reviewed all relevant mail threads and would like to
proceed as follows.

We believe that we are close to resolving all outstanding issues
raised during the WG Last Call on the requirements draft. However,
because we haven't reached consensus on three important issues,
we are, at this point in time, not able to proceed as Co-Chairs
normally would by making a recommendation to our ADs to take
this draft to the IESG for consideration for IETF Last Call.

To help move us along towards a successful WG Last Call we've
summarized the WG discussion so far related to those three
outstanding issues below.

In these summaries, we have also proposed some new language for
the requirements in question. We are not proposing this language
to push the WG towards any particular solution. Rather, this
language is mostly intended to spark discussion of the issues
underlying the contention over the wording of these requirements.

These issues appear to be mostly centered around implying rather than
explicitly specifying whether or not certain security features such as
confidentiality, integrity, authentication, and authorization can be
"switched off by mutual agreement between replicas and sources" during
the context of initiating a replication session.

First, and not related to the security-related issues mentioned above,
there was an open question on requirement G9. Here it is again for
your convenience:

G9.  LDAP replication SHOULD support replication of directoryOperation
     and distributedOperation attribute types defined in standards track
     LDAP extensions. Future standards track specifications MUST include a
     "Replication Considerations" section which indicates how and whether
     the new feature operates in a replicated environment.

Kurt wanted to remove the last sentence. The Co-Chairs believe that
this requirement should be relaxed from a MUST to a SHOULD. While we
both firmly support the spirit of the requirement, it will be very
difficult to actually enforce. Furthermore, while we can enforce
this in the LDUP WG, there are many non-LDUP-related controls/extensions
that are being developed. We don't think that it is permissible or even
possible for LDUP as a WG to act as a "policing force" for all
Internet-related work. However, as discussed on the list, there
are good reasons for making this requirement a SHOULD rather
than omitting it.

So, our proposed new text is:

G9.  LDAP replication SHOULD support replication of directoryOperation
     and distributedOperation attribute types defined in standards track
     LDAP extensions. Future standards track specifications SHOULD include
     a "Replication Considerations" section which indicates how and
whether
     the new feature operates in a replicated environment.

Second, there is the S1 requirement. Kurt suggested some wording changes,
but Chris and I would like to suggest some more that will help further
clarify what the current requirement wording implies. First, the
requirement and Kurt's suggested change:

| > S1. During initiation of a replication session, authentication and
| > verification of authorization of both the replica and the source
| > directory MUST be allowed before any data is transferred.
| I would suggest a cleaner wording:
| S1. The protocol MUST support mutual authentication and verification
|     of authorization of the protocol's peers before allowing
|     replication data transfer.

The problem is that there are several concepts that are jumbled together
into a single requirement. We propose, as a starting point for discussion,
the following three requirements to take the place of the above:

	S1a. The protocol MUST support mutual authentication of the source
	     and the replica directories during initialization of a
           replication session.

	S1b. The protocol MUST support mutual verification of authorization
	     of the source to send and the replica to receive replicated
           data during initialization of a replication session.

	S1c. The protocol MUST also support the initialization of anonymous
	     replication sessions.

Note that we explicitly discuss anonymous replication. We feel that this
issue has been brushed under the table, and want to tease it out into the
open. We are not explicitly recommending the support of this feature;
rather, we want to gauge whether or not consensus has been achieved for
including or excluding support of this in implementations.

We also feel, based on list discussions, that one additional issue
hasn't been fleshed out fully. This is the issue of whether a data
set MAY be relevant to determining if these entities are authorized to
actually follow through with the process of replicating the data. We note
that the data set for which replication is being initiated MAY or MAY NOT
itself be relevant to the actual process of authentication of the entities
involved. We would recommend that some additional discussion regarding
this point be undertaken on the list and that proposals be made for any
additional requirements related to that discussion be posted to the list.

The third requirement to continue discussion on is S2. It, along with
Kurt's suggested change, is repeated here below for your convenience:

| | > S2. The transport for LDAP synchronization MUST permit assurance of
| | > the integrity and privacy of all data transferred.
| S2. The replication protocol MUST support transfer of data with
| integrity and confidentiality protection.
| (I note this broadens the requirement)

First, we note that definitions for confidentiality and integrity are not
present in the draft. They should probably be added. But for the sake of
our purposes, consider the following definitions:

	Confidentiality: the assurance of data privacy; no one may
			     read the data except for the specific entity
			     (or entities) intended.

	Integrity: the assurance of non-alteration of data; the data
		     (either in transit or storage) has not been
		     undetectably altered.

Given these definitions, we'd like to start with Kurt's changes
and move forward. The above definitions render the use
of the word "protection" unnecessary. In fact, using that word
in a requirements document seems to push too close into protocol
design, based on reading many relevant texts on security
technology and concepts. A system cannot legitimately provide
assurance that data has remained private and/or was unaltered
during transmission if appropriate cryptographic techniques
are not employed to provide such protection. Thus we feel
that the use of the word "protection" in this requirement
pushes the document too close to the specification of the
replication protocol itself. It would certainly be appropriate
to include prose in the replication protocol document specifying
a framework within which such protective measures should be
implemented, but the requirements language proposed in this
e-mail should be sufficient to result in such a framework
actually being specified - which we believe is one thing
that the requirements document is supposed to help the WG
accomplish.

The original requirement indicates (using language that is less
than ideal) that we must be able to check on whether integrity and
privacy were maintained during data transfer, whereas Kurt's says that
the protocol itself MUST support data transfer with integrity and
privacy and implies that implementations SHOULD NOT support data
transfer without integrity and privacy features enabled. Whether or
not anyone actually agrees about whether this implication exists is
not in issue - that two people such as the co-chairs could independently
come up with this as one of a few different interpretations of this
requirement is. This indicates that the requirement is not explicit
enough to avoid potential related interoperability problems.

We would like to see some discussion of how it is envisioned that
replication sessions operate in trusted environments. In particular,
we are concerned with how integrity and/or confidentiality requirements
may be levied against operational replication processes, taking into
account the overhead those requirements imply. Some *service* implementers
making use of LDAP replication are likely to want a replication
protocol that enables them to decide whether or not integrity and
confidentiality are really requirements for their particular operational
scenario. Thus we are compelled to make the following proposal to
decompose the original requirement as follows:

	S2a. The replication protocol MUST support transfer of data with
           integrity and confidentiality.

	S2b. The replication protocol MUST support the ability during
	     initialization of a replication session for an authenticated
	     source and replica to mutually decide to turn off data
	     integrity and confidentiality within the context of and for
           the duration of that particular replication session.

We are not stating that this particular wording should be used in the
next revision of the requirements document. We are proposing it as
a way of encouraging open discussion of an issue which is neither
adequately, nor explicitly addressed in the requirements document.

regards,
John and Chris

Chris Apple
Program Manager - Directory Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email-masked]> 
(V) 610-425-2860

---

From: Christopher Apple <[email-masked]>
Date: Wed, 6 Jun 2001 18:50:46 -0400

What you wrote seems consistent with what we meant to me.

However, there is still the issue of language or wording
to resolve for the existing requirement so that its more
clear. And perhaps explicitly references the changed
requirement M7?

Chris Apple

-----Original Message-----
From: Richard Huber [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 5:06 PM
To: [email-masked]'
Cc: Christopher Apple; John Strassner (E-mail)
Subject: Re: WG Last Call Status of Requirements Document

The authors have discussed this comment.  It seems to pertain more to
architecture than requirements.  Here's how we think it would work:

 - the identities of the two endpoints involved in replication are
established
during inititation of the replication session
 - the identity allows each party to find the appropriate replication
agreement

 - the replication agreement specifies the area(s) of replication that these
particular entities are allowed to replicate (among other parameters)

In support of this view, we will add "area(s) of replication" to the list of
items in requirement M7 that "MUST be defined in a standard location (e.g.
the
replication agreements)".  Beyond that, this seems to be more of an
architecture issue than a requirements issue, so we propose that any
additional
discussion be in the context of the architecture.

If we've misunderstood the point of the comment, I'm sure you'll let us know
:-)

Rick Huber

---

From: Christopher Apple <[email-masked]>
Date: Wed, 6 Jun 2001 19:52:28 -0400

Comments below...

Chris Apple

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 6:17 PM
To: Christopher Apple
Cc: [email-masked]'; John Strassner (E-mail)
Subject: Re: WG Last Call Status of Requirements Document

At 07:34 AM 6/4/2001, Christopher Apple wrote:
>Kurt wanted to remove the last sentence.

To reiterate: it is my opinion that this sentence does not
state a requirement upon the LDUP architecture, model, protocol,
or other aspect of LDUP WG charter work items.  It is a requirement
upon designers of other extensions to detail replication
considerations.  As such, I believe it is beyond the scope of
this document.  It would be more appropriately be defined in
a document detailing how to design LDAP extensions (such as
Bruce's I-D).

CHRIS> I've had similar thoughts lately. However, I need to hear
CHRIS> some hum of concurrence on the list before we could declare
CHRIS> that this is what we actually will do with this document.

I note as well that "requirement" I-Ds such are only guidelines
meant to focus the work effort.  While the LDUP WG is somewhat
bound by its charter to work through a requirements process,
others developing LDAP extensions can simply ignore this document.

While I agree that it is appropriate for designers of
extensions to note a wide variety of considerations, there
is no need to mandate that all future standard track
specifications contain such sections.

CHRIS> I couldn't disagree more with that statement. The only place
CHRIS> where I'm more flexible as a consumer of RFCs and I-Ds on
CHRIS> these sorts of matters is about the strength of these types
CHRIS> of requirements. Some of them can be justified as a MUST,
CHRIS> others as a SHOULD. Perhaps even weaker labels are feasible,
CHRIS> but I can't think of an example for using them in this context.

CHRIS> It is actually quite common in the IETF to mandate that
CHRIS> certain types of document sections be present. See
CHRIS> RFC 2223 (ftp://ftp.rfc-editor.org/in-notes/rfc2223.txt)
CHRIS> as an example. Note that different sections of an RFC
CHRIS> are mandatory while others are not. My assertion is that
CHRIS> a replication considerations section SHOULD be included
CHRIS> in all future LDAP extension/control RFCs. Otherwise,
CHRIS> you end up with inconsistently thought out documents used by
CHRIS> different implementers and you are set up for interoperability
CHRIS> problems in droves.

I note that to address LDAP replication considerations in an
LDAP extension document requires that there be some technical
specification of LDAP replication.  This is very little to
consider (other than to say "This document does not consider
LDAP replication issues as there is no standard track
specification of LDAP replication").  This requirement attempts
to put the cart before the horse.

CHRIS> Putting the cart before the horse happens all the time
CHRIS> in the IETF. Over time, usually, the horse finds its way
CHRIS> to where it should be. :)

>The Co-Chairs believe that

The only reason I can see for such a requirement is so that
someone can say to an author "You didn't fulfill this requirement".
I would much rather this person say "You need to address replication
issues such as ...".

CHRIS> I don't think that word choice in communicating this particular
CHRIS> type of message is relevant to the fundamental issue of
CHRIS> requiring such a section or not. Referring someone to a spec
CHRIS> on how these types of documents must be written, by stating,
CHRIS> "You didn't fulfill [the referenced document] requirement"
CHRIS> shouldn't have a significantly different impact on the document
CHRIS> itself than that author being told in a mailing list posting
CHRIS> that they need to address replication issues. Especially if
CHRIS> that author is conscientious enough to follow up on considering
CHRIS> all comments objectively. However, because of the importance
CHRIS> of considering replication issues when writing LDAP extensions
CHRIS> given that LDUP will be implemented by several major LDAP
implementers,
CHRIS> I believe that the needs of the extended LDAP implementation and
CHRIS> user communities will be better served in the long run if authors
CHRIS> of extension I-Ds are told in *both* ways. One is explanatory and
CHRIS> the other is a requirement documented somewhere. This is completely
CHRIS> independent of the issue related to whether or not this requirement
CHRIS> belongs in the document its currently in.

>     the new feature operates in a replicated environment.

Please note my objections to inclusion of this requirement
as either a MUST or a SHOULD.  I suggest that this sentence
not use an RFC 2119 imperative.  That is, I believe it should
be worded as a suggestion to developers of future standard
track specifications.

CHRIS> OK. I understand. John and I need to hear what others think
CHRIS> about this. So far, we've only heard from you and I. That's
CHRIS> insufficient to judge consensus that this requirement be removed
CHRIS> from this document.

>our purposes, consider the following definitions:

I suggest use of RFC 2828 definitions in this I-D.  In particular,
I note that the term "data privacy" should be avoided (see RFC2828).

CHRIS> Please note that the requirements language proposed
CHRIS> to spark discussion doesn't make use of the term
CHRIS> "data privacy." RFC 2828 is intended as guidance
CHRIS> for writing I-D and RFC content (referred to
CHRIS> as ISDs in RFC 2828) and the author's thereof and not
CHRIS> mailing list discussions. So even if the proposed reworded
CHRIS> requirements were actually included in the next revision of
CHRIS> the requirements document, we would be in compliance with
CHRIS> RFC 2828 from the perspective of avoiding the use of the
CHRIS> term "data privacy."
CHRIS>
CHRIS> We weren't suggesting that these definitions be included
CHRIS> in the requirements document - only that they be considered for
CHRIS> discussion purposes.

>                     (either in transit or storage) has not been

CHRIS> If we wanted to be more consistent even in mailing list
CHRIS> discussions with RFC 2828, these would become:

data confidentiality
      (I) "The property that information is not made available or
      disclosed to unauthorized individuals, entities, or processes
      [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See:
      data confidentiality service.)

data integrity
      (I) The property that data has not been changed, destroyed, or
      lost in an unauthorized or accidental manner. (See: data integrity
      service.)

      (O) "The property that information has not been modified or
      destroyed in an unauthorized manner." [I7498 Part 2]

      (C) Deals with constancy of and confidence in data values, not
      with the information that the values represent (see: correctness
      integrity) or the trustworthiness of the source of the values
      (see: source integrity).

CHRIS> Even given those definitions as pulled from RFC 2828, I can't
CHRIS> see how the requirements language proposed for discussion
CHRIS> purposes below could be interpreted as inconsistent with RFC 2828.

---

From: Christopher Apple <[email-masked]>
Date: Mon, 11 Jun 2001 11:44:03 -0400

Just spoke with Rick on the phone about this.

The requirement wording has been adjusted from
the original by adopting proposed language from
John and I and making a few text changes here
and there for clarity; in particular to be sure
we use consistent security-related wording
and that this wording is compliant with RFC 2828.

The issue that I raised in the posting below
is resolved.

Chris Apple

-----Original Message-----
From: Christopher Apple 
Sent: Wednesday, June 06, 2001 6:51 PM
To: 'Richard Huber'; [email-masked]'
Cc: Christopher Apple; John Strassner (E-mail)
Subject: RE: WG Last Call Status of Requirements Document

Chris Apple

-----Original Message-----
From: Richard Huber [mailto:[email-masked]]
Sent: Wednesday, June 06, 2001 5:06 PM
To: [email-masked]'
Cc: Christopher Apple; John Strassner (E-mail)
Subject: Re: WG Last Call Status of Requirements Document

 - the replication agreement specifies the area(s) of replication that
these
particular entities are allowed to replicate (among other parameters)

In support of this view, we will add "area(s) of replication" to the
list of
items in requirement M7 that "MUST be defined in a standard location
(e.g. the
replication agreements)".  Beyond that, this seems to be more of an
architecture issue than a requirements issue, so we propose that any
additional
discussion be in the context of the architecture.

If we've misunderstood the point of the comment, I'm sure you'll let us
know
:-)

Rick Huber

---

From: Christopher Apple <[email-masked]>
Date: Tue, 12 Jun 2001 11:46:20 -0400

Yup.

Chris Apple

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, June 12, 2001 11:00 AM
To: Mark C Smith; Kurt D. Zeilenga
Cc: Christopher Apple; [email-masked]
Subject: RE: WG Last Call Status of Requirements Document

I think that the replacement that Mark is suggesting better reflects the
original intention of Chris and myself. Plus, semantically, it is
clearer.

regards,
John

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark C Smith
Sent: Tuesday, June 12, 2001 6:52 AM
To: Kurt D. Zeilenga
Cc: Christopher Apple; [email-masked]'; John Strassner (E-mail)
Subject: Re: WG Last Call Status of Requirements Document

"Kurt D. Zeilenga" wrote:
> These two requirements would adequate address my concerns in this
area.

I would like to see the phrase "turn off" replaced with "disable."  To
me, "turn off" implies that data integrity and confidentiality is "on"
by default which is not necessarily the case.  Otherwise, I like both of
these requirements.

-Mark