[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Security Last Call Initial Questions



On Mar 24, 17:29, bound@zk3.dec.com wrote:

%1.  Is draft-ietf-ipsec-arch-00.txt going to be an Informational RFC
%    only?

%    The reason I ask is that there is much text in ipsec that does not
%    apply to an actual implementation, but is history, opinions on
%    directions, and boilerplate type material.  I believe this is good
%    data in an Informational RFC like the Hinden IPng White Paper and
%    useful to the IETF community at large, but not necessary or useful
%    in a proposed standard.  The standard that goes with the IPng White
%    Paper is the Deering/Hinden IPv6 Base Specification, which is a good
%    example of how a standard to implement should be written.

	At present, the architecture document contains significant
amounts of standards-track material (to give one example, the
definition of a "Security Association", as that term is used by both
ESP and AH, only exists there).  Hence that document currently needs to
be on the standards-track.  Much of the material common to ESP and AH
specifications was moved into the Security Architecture document in
response to suggestions from others (including Scott Bradner) that the
material common to both the ESP and AH specs should be consolidated
into the Security Architecture draft.

	That standards-track material needs to be in a standards-track
RFC that moves in parallel with the ESP and AH drafts.  If the Sec
Arch document were not standards-track, then that standards-track
material would need to be moved into a standards-track draft prior to
Proposed Standard RFCs being issued.

% 2.  DES-CBC Encryption.  Could I get the formal answer to this question
%    from you for the record?  This question could also be asked of the
%    IESG at that Last Call effort too [if necessary].
%
%    An IPv6 implementation is required (MUST) to implement DES-CBC.  Yet
%    in my country (U.S.A.) being conformant means that vendors MUST
build
%    a product that cannot be exported to the International market.
%    Changing it to SHOULD would eliminate this objection to the draft.

Please permit me to make a correction.

	DES _is_ exportable from the US.  Depending on how it is going
to be used and the intended customer, export of DES might require an
export license from the US Government.  There are many known cases of
such export licenses being issued.  There is widespread belief that it
can be time consuming to obtain such export licenses.

%    Why cannot we use the word SHOULD?

	There is rough consensus that implementation of encryption is
mandatory for IPv6.  The word "MUST" is used to indicate mandatory
items.  The word "SHOULD" is used to indicate items that are not
absolutely mandatory.  Changing "MUST" to "SHOULD" would decrease
consensus because it would eliminate the requirement that encryption
be implemented in all IPv6 systems.

% 3.  The term 'userid' is used in the drafts for the sending host.
%
%    What is the 'userid' and how do I know as an implementor where I get
%    the userid on a node?

	A "userid" is an implementation-specific identifier used to
distinguish between different users of a system.  In the case of
POSIX.1 systems, the "uid" would map nicely to a "userid".

	Implementation-specific methods are used to obtain a userid.
In the case of a UNIX operating system, the getuid() or geteuid()
calls might be used by an implementation.  On other systems (for
example, HP MPE or IBM MVS), other implementation-specific calls would
be used.

% 4.  Could we have examples of manual configuration, host to host
keying,
%    and user to user keying?
%
%    I am not sure how I should implement any of these, and in the case
of
%    user to user keying, I am not clear what that actually means?


Are you reading the most recent documents ?

	I don't believe the terms "host-to-host" and "user-to-user"
appear in the current drafts.  If they do, it is an editing error that
I somehow missed.  The corrected terms are "host-oriented" and
"user-oriented" keying.  The text in this area was completely
rewritten in response to feedback from various people.  The text
should be reasonably clear in the current draft.

	I believe the existing text noted that manual configuration
could mean that one put the keys and other data in a flat file.  If
desired, I could create an informational (i.e. not standards-track)
appendix illustrating one possible flat file format that could be
used.

	There is significant detail in the ESP and AH drafts on the
process by which an incoming or outgoing packet is handled.  The
combination of that text and the text in the Security Architecture
makes clear how to implement this.  This is one of several reasons
that the ESP and AH drafts cite the Architecture draft as
standards-track.  All 5 drafts need to be read as a set.

% 5.  In 4. Key Management section.
%
%    'Support for key management methods where the key management data is
%    carried within the IP layer is not a design objective for these
%    IP-layer security mechanisms.'
%
%    If this means it will not work then I think a standard should say
%    that, or else say nothing.  Saying this means nothing to me as an
%    implementor.  I cannot test for this case, so why is it an
%    implementation standard?
%
%    This last point is critical.  Statements in standards for which I
%    cannot implement as a test case is suspect as to the words being
%    useful for an implementor.

	There is rough consensus that this information is important to
implementers so that there is a clear understanding of what the design
objectives were and were not for the security specifications.
Removing that language would decrease consensus.  Many existing
Internet standards contain similar language about design goals.  The
IETF document style is significantly different from that of other
standards groups such as IEEE and ANSI.  This document complies with
IETF document style because it is an IETF document.

% 6.  Security warnings and statements of potential attack.
%
%    Would it be possible to put these in an appendix, when they are not
%   in the standard to provide implementation details?

	Within RFCs, the "Security Considerations" section is supposed
to describe security issues and residual security risks relating to
the material described in that document.  Moving these to an appendix
would not conform to IETF document standards (see RFC-1543, Section
8).  Further, removing that material would decrease consensus.

% 7.  The specs reference two new IDs (or work in progress) for MD5 and
%    DES-CBC?

%    These are new.  Are these the specifications you are stating to
%    implement MD5 and DES-CBC?  Because you have stated MUST, if these
%    specs cannot be made proposed in the same time frame as your
%    standard, it will hold up the IPv6 Security work from going to
%    proposed standard.  By saying SHOULD or they are an option, you free
%    your work from those work items reaching proposed standard IMHO.

	These were actually announced by the InterNIC prior to their
announcement of my drafts.  All 5 drafts were actually available
online at the Internet-Drafts directories for significant time prior
to their announcement by CNRI.  Further, all 5 drafts were ftp'able from
ftp.nrl.navy.mil even prior to their announcement by the InterNIC and
that location was announced by me to IPng and IPsec mailing lists.

	Those drafts contain much clearer text describing the security
transforms and are improved versions of the text formerly in Appendix
A of the ESP and AH drafts.  The revised text is based on
implementation experience of Phil Karn and Perry Metzger.
It is intended that all 5 drafts move forward as a set.


Ran
atkinson@itd.nrl.navy.mil




Follow-Ups: References: