[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI IPSEC WG Charter
Reply to: RE>FYI IPSEC WG Charter
Greg,
There have been some constructive comments on the charter in the last week
that should be incorporated into the text. I have taken the liberty to
develop a 2nd draft of the charter that incorporates these changes.
Following are responses to Joe TardoUs comments, a summary of changes to the
charter, and a 2nd draft of the charter.
>Now some more constructive comments, on Alton Hoover and Paul Lambert's
>Draft charter.
>
>1. What do you mean by "access control"? Do you mean labelling? Packet
> filtering? This should probably not be an early requirement.
Access control seemed to be a stronger requirement than confidentiality in
the discussions at the last BOF meeting. Access control can readily be
based on authenticated host addresses. Options for datagram labeling are
possible along with access control decisions based on these labels.
All of the services listed in the draft charter can be readily provided by
an RipsecS security protocol. All of these services should at least be
considered in the initial design. We attempted to qualify the charter to
allow various combinations of these services to be supported.
>2. Sprinkle "algorithm independence" in somewhere.
Ok! Added to the first paragraph of the charter as:
The protocol formats for ipsec will be independent of the cryptographic
algorithm.
>3. What do you mean by "integrity" for a datagram service? This is
> a snake pit if you are worried about replay.
Integrity can be provided by a Integrity Check Value (ICV). At a minimum
IPSEC can provide connection-less integrity without recovery. You are
correct that placing sequence numbers in a connection-less protocol to
provide complete protection from replay is controversial. The ISO 11577
Network Layer Security Protocol currently attempts to support sequence
numbers. Since we can readily provide the simplest connection-less
integrity service we should leave this goal in the charter.
>4. "Subnet-to-subnet ... recursive ... encapsulation" is a bit too
> specific for terms of reference.
This was specifically included by one of the contributors to the charter to
highlight a specific problem with the current NLSP specification. Currently
NLSP does not contain procedures describing the recursive encapsulation of
NLSP. You are correct that this is to specific to be in the basic charter.
IUve taken this text out of the attached draft.
>5. Key management - let's be realistic. I suggest the "minimalist"
> (KISS) approach to start: manual keying via SNMP (: duck :) with
> a nice little MIB. Next should come a peer-peer exchange in the
> layer ("Key Exchange Control Protocol"), something akin to what
> Phil Karn (others before him) have suggested, but as lightweight
> as possible. Later on (much later) should come the all-singing-
> all-dancing-802.10-KMAE-X9.17-compatible-Holy-Grail ultimate one-
> size-fits-all key exchange application, if ever.
I feel that the goals of the charter for key management are achievable.
Particularly if we do keep it simple at first as you suggest.
>6. Finally, is it integrated in IP or a sublayer? In other words, is
> this limited to "externally observable" interworking issues or are
> you going to delve into end-system interface issues? This starts
> to get into the "assurance" question...
I was pressing strongly for a sublayer approach that would define a security
protocol independent from IP. The charter was left slightly ambiguous to
leave this open for discussion. While I personally favor this layered
encapsulation, it is also possible to integrate any of these cryptographic
mechanisms directly into IP or IPv7. It seemed better to not close off this
discussion prematurely by becoming overly specific in the charter.
>The schedule looks OK for an encapsulating frame, no replay integrity
hacks,
>SP3-D-based protocol with MIB keying, end-system-to-end-system, no
assurance,
>no access control or authentication beyond "yup, key works!".
The SP3 specification has evolved into the ISO 11577 NLSP specification.
The connection-less mode of this document (NLSP-CL) is currently the
strongest contender for a Rstarting pointS for IPSEC.
Summary of changes to charter
Added in the first paragraph:
The protocol formats for ipsec will be independent of the
cryptographic algorithm.
Removed from the first paragraph:
Subnet-to-subnet topologies will support recursive cryptographic
encapsulation.
2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft
Internet Protocol Security Protocol (ipsec)
Charter
Chair(s):
Al Hoover <hoover@ans.net>
Paul Lambert <Paul_Lambert@email.mot.com>
Security Area Director(s)
Steve Crocker <crocker@tis.com>
Mailing lists:
General Discussion: ipsec@ans.net
To Subscribe: ipsec-request@ans.net
Archive: ftp.ans.net:~/pub/archive/ipsec
Description of Working Group:
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security protocol working group
(IPSEC WG) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality. The
protocol formats for ipsec will be independent of the cryptographic
algorithm. The preliminary goals will specifically pursue host-to-host
security followed by subnet-to-subnet and host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security. The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol. The protocol will
initially support public key based techniques. Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.
Goals and Milestones:
Mar 93 Post as an Internet Draft the Network Layer Security Protocol.
Jul 93 Post as an Interenet Draft the specification for Internet Key
Management.
Nov 93 Report on Pilot Implementation of the Network Layer Security
Protocol. Update Protocol as needed.
Mar 94 Report on Pilot implementation of the Internet Key Management
Protocol. Update Internet Draft as needed.
Jul 94 Submit the Network Layer Security Protocol to the IESG for
consideration as a Proposed Standard.
Jul 94 Submit the Key Management Protocol to the IESG for consideration
as a Proposed Standard.