Subject: RE: Question on security document

From: "Ofer Biran" <[email-masked]>
Date: Thu, 18 Oct 2001 20:25:59 +0300

Bill,

> you are required to have all of your dependacies
> at your level of standardization or higher

For iSCSI the references to the security document
definitely do not create a dependency.  e.g.:

"Further details on typical iSCSI scenarios and the
relation between the initiators, targets and the
communication end points can be found in [SEC-IPS]."

   Regards,
      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

"Bill Strahm" <[email-masked]> on 18/10/2001 18:50:44

Please respond to "Bill Strahm" <[email-masked]>

To:   Ofer Biran/Haifa/IBM@IBMIL, "Robert Snively" <[email-masked]>
cc:   "'Paul Koning'" <[email-masked]>, <[email-masked]>,
      <[email-masked]>
Subject:  RE: Question on security document

Here is the problem.

I create an informational RFC that includes compliance statements (I want
to
use 3Des, AES would be nice, etc.)
I create a standards track RFC and point to the informational RFC to
provide
security
I don't think you can do this - I know that you would not be able to go up
the standards track because you are required to have all of your
dependacies
at your level of standardization or higher (It makes no sense to have a
full
standard dependant on a standard that is at draft standard level)

Bob is technically correct.  What I hope this group does is pick up the
correct verbage from the security draft and put it into the standards
protocol documents, or put the security doc on the standards track

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Ofer Biran
Sent: Thursday, October 18, 2001 9:03 AM
To: Robert Snively
Cc: 'Paul Koning'; [email-masked]; [email-masked]
Subject: RE: Question on security document

Bob,

The intention of the security document was tutorial, elaborated discussion,
motivations and more detailed guidelines and recommendations for the
security aspects.

The "official" mandatory statements are only in the standard RFCs. I'm not
sure
about the IETF rule for informational RFC but I don't see a problem with
MUST
statements there as long as they are in sync with the corresponding
standard
RFC.

   Regards,
      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

Robert Snively <[email-masked]>@ece.cmu.edu on 18/10/2001 17:35:35

Please respond to Robert Snively <[email-masked]>

Sent by:  [email-masked]

To:   "'Paul Koning'" <[email-masked]>, [email-masked]
cc:   [email-masked]
Subject:  RE: Question on security document

Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol.

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles,

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 7:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Question on security document
>
>
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> >
> > I had assumed that one goal of the document was to set
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the
> suggested change may
> > compromise that intent.
> >
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:[email-masked]]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: [email-masked]'
> > > Subject: Question on security document
> > >
> > >
> > > I have a recommendation to the authors of the security
> > > document:
> > > ...
>
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
>
> So one answer is for the security draft not to be informational
> anymore.
>
>    paul
>
>

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 18 Oct 2001 10:32:15 -0700

In that case you can't have requirements (ie SHOULD/MUST) language in the
reference document...

There is a difference between typical scenarios and REQUIRED scenarios... ie
if you are saying that typically you will use IPsec with 3DES/SHA1 using
Aggresive mode IKE that is fine... If you want to say you MUST use IKE/IPsec
then you need a standards track document saying how you will do this.

Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm     Software Development is a race between Programmers
Member of the   trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
[email-masked] idiots.
(503) 601-0263  So far the Universe is winning --- Rich Cook

-----Original Message-----
From: Ofer Biran [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 10:26 AM
To: Bill Strahm
Cc: Robert Snively; 'Paul Koning'; [email-masked];
[email-masked]

Bill,

   Regards,
      Ofer

Ofer Biran

Here is the problem.

Bill

-----Original Message-----

Bob,

   Regards,
      Ofer

Ofer Biran

Paul,

Charles,

Bob