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

Re: IPv6 Security Last Call Initial Questions

Ran,

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

I think a 'pure' design document should be an info RFC.  Those parts
that define knowledge required to implement the standard should be moved
to AUTH and ESP.  

For example on Page 6 paragraph 3:

"The receiver-orientation of the Security Association implies that, in
the case of unicast traffic, the destination system will normally select
the SPI value."  

What does 'normally' mean to me as an implementor?  If its a case type
primitive I do not know from this spec what the conditions are for the
switch() or the the object for which the conditions are being tested.
But as an information statement I can accept it as it is presently.  I
could go through the spec and point out other places where the wording
is of this nature. 

Also in the above and in other places replace system with node, per IPv6
base spec.

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

Or just put what you need in AUTH and ESP drafts.  Less is better in
many cases (not in all I realize).

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

A correction to your correction.  This is common knowledge, but some
countries are more difficult than others per agreements with those
countries.  Not all countries can recieve export licenses one will want
to do business with simply because of government policy.  This is the
problem and the IETFs' in making standards not the vendors. 

Also this does not change the fact that requiring DES requires vendors
to build products that may not be exportable in their country.
Conformance can mean that reaching an international market with that
product is prevented.  We are trying to make the Internet more
International and easier to business with in that manner not less.

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

Well I do not agree with you that this has rough consensus.  I
challenge any claim to rough consensus in the vendor community,
which is a large part of the IETF community.  Not sure how either of us
prove this one way or the other?

% 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".

I know that, in fact my name is on that standard and I worked on it.  
My point is that we should say more about what a userid is so it is
clearly defined.  Putting it under terminology or technical definitions
in AUTH or ESP would be a good idea IMHO.

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

But in UNIX they could be the same across systems, they are not
guaranteed to be unique, anymore than process-IDs.  This is true for other 
systems including a POSIX Conforming System.

As long as you brought up POSIX take a look at POSIX.3 Test Methods and
Conformance.  This is where assertions are developed to test the code
implementation details of POSIX.1, as one case.  It clearly points out
the problems with standards that are written for which a test case
cannot be defined.  Hence, producing bugs in implementations.  I am
having trouble with the assertions for testing in the spec.  A good
example of specs that are very clear are the IPv6 base spec, IPv6 System
Discovery, and the new IPv6 Transition spec (except for tunnel state/config 
which is complex).  The security specs do not have this manner of 
implementation clarity.

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

They do say user-oriented now, my mistake when responding.  Its not
clear because its not stated how the user-oriented key is passed to the
other implementation.  Also stated that "User A on host 1 might have more 
than one key for its traffic destined for host 2", seems contradictory
to user-oriented keying?  Unless two-way sessions are not to be
established?

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

I think we need more than that?  An explanation of what it means to an
implementation and where/how the manual key is used in the protocol I
think at a minimum should be stated if this is a MUST.  

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

Then make them one draft.  I should not have to read ESP to implement
AUTH.  I should not have to read SEC to implement any draft.  Except for
parts that should be moved to the AUTH and SEC drafts.

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

I do not agree we have rough consensus on this issue.  in-band can work
with your architecture.  There is no good reason to state this is not a
design objective.  If it will not work then the 'warning' should be
noted.  Its my impression it can work and I can implement it that way if
I choose for customers who want to use in-band who do not need or
require perfect forwarding security.

I am well aware of the IETF style no need to remind me, and that is not the
issue at hand.  Also this was not under the Design Objective section
fyi.  I have worked on several styles of standards including defacto as
opposed to dejure.  What I like about the IETF is the notion of
implementations are critical to prove a techncial belief.  What I am
questioning is the implementation thinking behind the specs.  In that
effort as an engineer I also must consider cost, and having to build
eeventual products to specifications that increase costs or prevent
other products is prudent on my part as an engineer to question what I
am questioning.  Its not a witch hunt or pick on Security.  These issues
are all important so we are very sure we get Internet security right for
all parties concerned.  Including us engineers, who are stuck with being
concerned about cost as part of our trade.  This security is very costly
to all: reduces performance, no key management in sight, conformance to
a standard could mean I can't export a product, statements that limit
what kind of keying is good for this architecture, and many statements
that say "this is unclear" or "in the normal case" while I am reading an
implementation spec.  Thats why the IETF is good too.  I can ask and
check the implementation details consistently until they are clear and
implementable at a reasonable cost.  Add no key distribution as another
issue as an unknown.

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

I am not talking about a "section" but the consistent warnings "throughout"
the documents.  I agree we need them, so put them all in one seciton as
you suggest above.

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

Were these implementations on an IPv4 stack or IPv6 stack?  What IP
kernels were changed to accomodate the tests?  What we used for IPv6 was
RFC 1321. The new MD5 seems to add value but we have not had time to
test it in code yet.  DES-CBC is another issue per above, but I guess we
could prototype it in the U.S. from an advanced development perspective
to test the implementation of the specs, as IETF participants and team
players in the IETF.

/jim
References: