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

Re: Granularity of authentication in swIPe




"marcus (m.d.) leech" says:
> How does this relate to IPSP/swIPe?  It occurs to me that swIPe would be
>   a potentially better way for us to go in the long-term, but there is
>   an implicit assumption in the protocol that an authenticator is bound
>   in some way to a source ip-address, and not an individual user of the
>   network.  That is, a swIPe packet carries with it an AUTHENTICATOR, but
>   no corresponding IDENTIFIER.  Unless I've mis-read the I-D.

Of course it is bound to the IP address, just as a TCP port number
makes sense only in the context of an IP address. There isn't any way
to get around this -- networks connect computers, not people. That
said, if you want to authenticate on a user level, you simply have a
user controlled program negotiate a policy between the two hosts using
authentication information that would only be known by the user. For
instance, the user's public/private key pair could be an element of
the negotiation, thus demonstrating that only the entity holding that
private key could have been involved in the negotiation of the keys
for that policy. Given that, if your system has reliable information
that only that user should be in possession of the private key in
question, then you can know that the user (or someone who has stolen
his key) is the entity on the remote host. (Kerberos could also be
used for such a negotiation -- I'm just a fan of public key methods.)

swIPe is NOT a key management system or a key negotiation system. Its
just a way of standardizing the encapsulation of authenticated and
encrypted IPv4 packets. On top of it, it is possible to build a wide
variety of systems. You can, for instance, build a system that permits
negotiation on a per user basis as described above and use it on top
of swIPe -- that is in fact the intention. However, swIPe is not a
layer that knows about users, just as IP is not a layer that knows
about users.

Perry


Follow-Ups: References: