[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: Human I&A, IPsec, and their non-relationship
Charlie Watt says:
> Perry,
>
> I may finally understand. Is this an accurate summary:
>
> The network layer security protocol adopted by IPSEC should provide
> host-to-host security services, including peer-host authentication.
Yes, so far as it goes.
> It may be beneficial to allow multiple security associations between
> a given pair of hosts.
Here, I'd say that we MUST allow multiple security associations
between a given pair of hosts. Ignoring all other questions, simply
having different levels of security/performance tradeoffs for
different communications requires it.
> If so, no specific connotation is implied
> for the different associations -- such meaning might be determined by
> the individual NLSP service consumers, or by a specific implementation
> of the NLSP.
Correct from the point of view of the NLSP documents -- that is, the
NLSP must provide multiple associatiosn, and mustn't try to figure out
what they mean, as it isn't the business of the network layer.
However, in order to be able to manage these multiple associations, it
is going to be necessary to allow transports and applications above
them to pick which association is used for which socket.
For instance, say that you want (for whatever reason) all your SMTP
traffic authenticated with MD5 and all of your telnet traffic
encrypted with RC4. Unless the transports can tell the network layer
"oh, by the way, please use SAID #567945 with this packet I'm about to
hand you" there is no way to accomplish this. Given the facility to
have applications tell the transport to use a particular SAID and to
have the transport pass that information through to the network layer,
however, it becomes possible to do this sort of per socket
association. I'd say that being able to do that sort of thing is a
requirement OF THE FINISHED IPSEC SYSTEM, but not of the network layer
security protocol PER SE. The NLSP qua NLSP just has to be able to
support multiple associations.
I'll point out, by the way, that if you don't support multiple
associations between a pair of nodes you don't need SAIDs and can get
along perfectly well without them -- at that point you simply know
from negotiation what the one and only security transform and key in
use between a host pair are and there is nothing more to say on the
matter. The whole point of SAIDs was to make multiple associations
between hosts possible.
> To provide its services, the NLSP requires the use of a key management
> service.
Yes...
> As there will be other IETF protocols and services
> requiring key management, and as it is desirable to minimize the
> number of overlapping protocols, the key management protocol developed
> for use by the NLSP should support (or at least not preclude) use with
> these other services, such as user authentication.
Correct as far as it goes. One of my other points, however, is that
given a facility that makes it possible to set SAIDs on a per socket
basis one can then take one more step. If an SAID is associated with a
particular user/userlike entity pair as a result of a key negotiation,
then one can let applications draw inferences about what the identity
of a remote entity initiating communications is without having to
involve the applications in key negotiation at all. That is to say,
one can have, say, an rlogin daemon note that the socket that just was
established was labeled with SAID #76583, and that SAID #76583 was
established (according to information stashed by some layer above the
key negotation layer) by the key association with the principal name
"joe@foo.com". It can then infer that the remote entity is the entity
that has the private key associated with "joe@foo.com" and check an
access control list to decide whether to automatically log in
"joe@foo.com" as the user "jsmith", as requested by the remote rlogin
client.
In short, one can build very nice tools given the ability to have
per-socket settable SAIDs, and given the ability to draw certain
inferences about remote entities based on identifiers attached to keys
used by the key negotiation/management layer. These tools have many of
the properties of Kerberos like systems and allow us to build secure
applications. Any specification that would impede constructing things
this way is, IMHO, a bad idea, although I would certainly not mandate
having the transport layer know anything about users or even what
SAIDs are used with beyond the fact that it can be asked to request
that the IP layer use a particular one.
None of this places any requirement on the NLSP beyond being able to
handle multiple associations between a host pair that are semantically
undefined at the NLSP layer. None of this places any requirement on
the key management layer beyond being able to handle establishment of
multiple associations between hosts using keys that some entity on the
hosts possesses.
Perry
References: