[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Granularity of authentication in swIPe
- To: ipsec@ans.net
- Subject: Granularity of authentication in swIPe
- From: "marcus (m.d.) leech" <mleech@bnr.ca>
- Date: Tue, 14 Jun 1994 16:05:03 -0400
- Organization: Bell-Northern Research, Information Technology Division
- X400-Content-Type: P2-1984 (2)
- X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.962:14.05.94.20.05.05]
- X400-Originator: /dd.id=1638487/g=marcus/i=md/s=leech/@bnr.ca
- X400-Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 14 Jun 1994 16:09:30 -0400
- X400-Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 14 Jun 1994 16:09:30 -0400
- X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 14 Jun 1994 16:09:30 -0400
- X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 14 Jun 1994 16:09:30 -0400
I just read the swipe I-D. My comments are from the point of view of someone
involved in providing secured access to a corporate network from
coporate networks of other companies networks. We have three major
requirements:
a) Transparency of client/server communications, both for TCP and UDP.
We need more than managed TELNET and FTP access.
b) Granularity of identification down to the individual user level.
We don't necessarily trust all of the individuals from another
corporation, and they may migrate from ip-address to ip-address.
c) Use of a firewall/bastion host to mediate access.
Both for high-confidence isolation, and session-layer logging.
We perceive that we have two choices here:
a) Embed Kerberos in every client/server application we have control over.
This may involve cross-realm authentication.
b) Use an encapsulation scheme, like SOCKS, with some authentication
extensions.
We have decided that for the short-term, we want to use (b), since we can
implement it entirely at the user-level, without custom kernels and
custom router software; and with a few clever tricks, without recompiling
any code. Further to that, I'm working on a document
that I hope to make an I-D to describe SOCKS encapsulation, with the
authentication extensions I mentioned. Like swIPe, the new SOCKS
protocol specification defines authentication information very loosely,
relying on 'out-of-band' techniques for key-management, etc.
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.
--
Marcus Leech |Any opinions expressed are mine. |+1 613 763 9145
VE3MDL | and not those of my employer |+1 613 567 5484
mleech@bnr.ca | |
Follow-Ups: