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

Re: FWD: Re: FYI IPSEC WG Charter




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

Client protocols seems like a nice way of putting it given that in IP
ICMP/DNS/Routing/etc. are all "clients 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.  

Well, while the formats need to be independent of algorithm, they need
some way to talk about this so parties can agree on algorithms.

If you have a good host-host algorith, you can easily do
subnet-to-subnet and host-to-subnet by having the subnet proxy for the
hosts.  It's only if you want multiple layers of
authentication/encryption/etc. that this is somewhat different.  I
believe that it will be important to keep this possibility in mind and
that if this possibility is kept in mind, then there will not be that
much work involved in developing a subnet-to-subnet level protocol.

An example: Consider a local network with a trusted host T and lots of
less trusted workstations W1, W2, ...  There might be another such
network controlled by the same organization with untrusted lines in
between (does not matter if these lines go between adjacent buildings
or between continents).  Subnet-to-subnet security between the two
local networks is basicly the way to go here although you might also
have host-host security turned on for all these machines.  But lets
throw an additional requirement in: the strongly trusted host(s) need
to also communicate with some machine(s) M* outside of this cozy
arrangement.  Either this machine is a source of necessary information
to be processed or maybe it's a trusted machine but in any case it is
not on a trusted/secure net.  So you have this nice strongly trusted
machine T that is trapped inside the subnet-to-subnet security so it
can't talk to M* .

Well, it could have a second hardware network interface to evade
this...  Or the software on M* could proxy for a secure network but
that might require developing special software to do this.  But I
think the right thing is, in the initial host-to-host protocol to add
a "punch-through" bit that requests the supression of all higher
levels ("subnet-to-subnet" or the like) of security.  Default
configuration would be to reject outbound packets with this bit on at
the secure subnet level but optionally a secure subnet could be
configered to honor this request from one or more trusted hosts in its
net (would require outbound packets from that host to be
authenticated) and to allow inbound packets addressed to that host
that have not had subnet security applied to them (could require
host-host security to have been applied to these packets).

Anyway, my point is that there may be things like this that could be
considered a good idea, but you might not have even thought of it if
you did not keep the possibility of an additional level of
subnet-to-subnet security in mind.

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

I'm not sure exacely what is meant the the above but it seems much too
restrictive to me.  I think of key management as somewhat orthogonal
to cryptographic algorithm.  Assuming you have some way for parties
negotiating a "secure" (ie, provides one or more of the 4 services
listed above) connection to negotiate about the cyrptographic
algorithm(s) they are going to use, why can't they also negotiate the
key exchange mechanism?  There is nothing wrong with a generally
accepted applications level protocol; it would be a good thing.  But
why would something so much simper (if more cumbersome) like manual
key distribution, which it seems like you would want to use in
debugging the "secure" connection mechanism, come later than an
applications level protocol which would be much more complex (although
more convenient)?  Why not allow the parties just to say to each other
that they are assuming manual key distribution as another possibility
to applications level public key (certificate, DNS, or whatever)?

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



Follow-Ups: