-------- From academic-firewalls-owner@net.tamu.edu Mon Mar 24 10:35:26 1997 In-reply-to: Your message of "Tue, 18 Mar 1997 14:48:19 +1200." Date: Mon, 24 Mar 1997 10:08:53 -0600 From: "David K. Hess" To: academic-firewalls@net.tamu.edu Subject: Re: firewalls and authenticated connections Well, I've been busy handling all the bounces as the list came back to life so I'm just now getting around to following up to this.... In message <199703180248.OAA05581@ccu1.auckland.ac.nz>, Russell Fulton writes: > We have recently contracted with a local ISP to provide dialup access > for students to the campus network. We have an E1 link to the ISP and > this lands on a router on our DMZ. We wish to make material available > to these students (and later others who may com in from the internet) > that we do not wish to make generally available via the Internet. (In > some cases because of copyright issues and others because in the > competitive climate of the 90's we don't want to share our teaching > material with other institutions :-( ) While we have our own dialup bank, we also end up with some folks using local ISPs. In addition to the issues you raise, we also have licenses that only cover students, staff and faculty that were typically enforced via IP access rules. This is of course breaking now. We have also come to the conclusion that a solution would be to have the ISP(s) assign a specific range of addresses to the students, faculty and staff. However, this is not a long term solution (even if IP address authentication were a secure mechanism in the first place). > Access will be IP only and mainly web but there is also some > departments who will need telnet and ftp. Longer term we will also > almost certainly be asked to support SMB. > > Long term, I believe, that we need to have authentication systems > (preferably kerberos) built in to all servers that are not wholely > public. But this is not practical in the immediate future with the > resources available so I am looking for an interim solution that can > be put in place fairly quickly at moderate cost. Well, I'm not much of a fan of Kerberos. Unfortunately, it may be the only coherent solution available in the near future. My preference (i.e. pipe dream) is strong authentication AND authorization via public key cryptography and directory services. I.E. SSL/SKIP/AKA style session authentication with the public keys and authorization information coming from a directory service such as LDAP. It looks like the web browsers are heading that way pretty quickly. The problem will be getting it into all of the other protocols. I'm really interested to hear other's opinions and experiences on this topic too. Dave - -- David K. Hess Network Group Manager David-K-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 25 05:13:26 1997 X-Authentication-Warning: farm6.central.cranfield.ac.uk: localhost [127.0.0.1] X-Mailer: exmh version 1.6.7 5/3/96 cc: academic-firewalls@net.tamu.edu, j.goldberg@cranfield.ac.uk In-reply-to: Your message of "Mon, 24 Mar 97 10:08:53 CST." <200.859219733@net.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain X-Mts: smtp Date: Tue, 25 Mar 97 10:48:16 +0000 From: P.Lister@cranfield.ac.uk To: academic-firewalls@net.tamu.edu Subject: Re: firewalls and authenticated connections > > Access will be IP only and mainly web but there is also some > > departments who will need telnet and ftp. Longer term we will also > > almost certainly be asked to support SMB. > > > > Long term, I believe, that we need to have authentication systems > > (preferably kerberos) built in to all servers that are not wholely > > public. But this is not practical in the immediate future with the > > resources available so I am looking for an interim solution that can > > be put in place fairly quickly at moderate cost. > > Well, I'm not much of a fan of Kerberos. Unfortunately, it may be the > only coherent solution available in the near future. Reasons? Do you object to Kerberos per se or private key systems in general? Public key management for a large student population is NOT an easy task. Kerberos works for Cranfield and MIT; how does TAMU differ? > My preference (i.e. pipe dream) is strong authentication AND > authorization via public key cryptography and directory services. I.E. > SSL/SKIP/AKA style session authentication with the public keys and > authorization information coming from a directory service such as LDAP. > It looks like the web browsers are heading that way pretty quickly. The > problem will be getting it into all of the other protocols. For WWW, I have Apache with SSL and server side Kerberos: users off-campus enter their Kerberos username and password; it's protected by SSL on the way back to the server. Only the server has an RSA key, which provides evidence of identity to the browser. Of course, most people won't check what lies behind the little blue key, but the point is that they can. For services where it's not practical to get inside the protocol (more to the point: where it's not feasible to get inside the *clients*; servers can usually be tweaked), I've been considering using a Kerberos client which can set up a per-session password with the server, and insert it into the right place for those clients which insist on caching passwords; a new password is arranged with the server on every login, hopefully transparent to the user. The other alternative is SSH port forwarding; a great idea (and it works with public or private keys) hampered only by the lack of a free/low cost SSH Windoze client. Datafellows won't sell site licenses (in the UK at least); even if they did, this doesn't help off site users. This is getting rather off the topic of firewalls, but I'm hoping that if we can have decent authentication from off campus this will convince the powers that be that putting one big firewall between our IP router/dialup modems and the campus is NOT a good thing, and that smaller firewalls with more tightly controlled policies between the campus net and individual depts will be far more effective. Peter Lister Email: p.lister@cranfield.ac.uk Computer Centre, Cranfield University Voice: +44 1234 754200 ext 2828 Cranfield, Bedfordshire MK43 0AL UK Fax: +44 1234 751814 The more we look at structures of trust, the more we realise that democracy and subversion are closely related. (Ross Anderson) -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 25 10:31:14 1997 X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <200.859219733@net.tamu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 25 Mar 97 08:11:47 Pacific Standard Time From: Peter Brantley To: academic-firewalls@net.tamu.edu Subject: Re: firewalls and authenticated connections Like most other schools, UC is also attempting to deal with this issue. Most campuses, including my own, have pursued or are pursuing ISP contracts to augment local campus dial in capacity. We have a large aggregation of databases, mostly A&I, called Melvyl, which is IP-restricted. The UCs are also aggressively pursuing contracts for full text information from a variety of traditional publishers. Publishers have to be educated about our issues - e.g., suggesting that we use userids to access content is clearly not feasible when we have over 100,000 potential users in the UC system. Similarly, we have a mess of IPs, ranging from a class A to a slew of class Bs, and a smattering of Cs. And then there are the national labs we administer .. so the situation is quite complex. We are beginning to propose the use of public certificates. This is tractable for publishers since most content is accessible only via web interfaces, and as mentioned, browsers are supporting this technology. Furthermore, it requires relatively little publisher education. It is possible we would utilize a hierarchy of certificate authorities - i.e., the UC system admin office would be the top level, with campuses subordinated as secondary certificate authories for their own communities. While this does manage to sidestep IP restriction, we have not managed yet to move beyond conversations in hallways and campus greens. ___________________________________________________________________ Peter Brantley - Director, Information Systems Library and Center for Knowledge Management UCSF - A Graduate Health Sciences Campus -------- From academic-firewalls-owner@net.tamu.edu Tue Mar 25 16:26:12 1997 In-Reply-To: <200.859219733@net.tamu.edu> X-Mailer: Simeon for Solaris Motif Version 4.1 Build (3) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date: Wed, 26 Mar 1997 10:17:24 +1200 (NZST) From: Russell Fulton To: academic-firewalls@net.tamu.edu Subject: Re: firewalls and authenticated connections On Mon, 24 Mar 1997 10:08:53 -0600 "David K. Hess" wrote: Firstly Thankyo David. > > Well, I've been busy handling all the bounces as the list came back to > life so I'm just now getting around to following up to this.... > > In message <199703180248.OAA05581@ccu1.auckland.ac.nz>, Russell Fulton writes: > > We have recently contracted with a local ISP to provide dialup access > > for students to the campus network. We have an E1 link to the ISP and > > this lands on a router on our DMZ.. We wish to make material available > > to these students (and later others who may com in from the internet) > > that we do not wish to make generally available via the Internet. (In > > some cases because of copyright issues and others because in the > > competitive climate of the 90's we don't want to share our teaching > > material with other institutions :-( ) > > While we have our own dialup bank, we also end up with some folks using > local ISPs. In addition to the issues you raise, we also have licenses > that only cover students, staff and faculty that were typically > enforced via IP access rules. This is of course breaking now. We have that too, Library has subscriptions to many online services that can be accessed via their web proxy. We currently control access by IP number. It gets worse, because some these services are expensive the library wants to recover the cost by charging for access. This means identifying people not machines... > > We have also come to the conclusion that a solution would be to have > the ISP(s) assign a specific range of addresses to the students, > faculty and staff. However, this is not a long term solution (even if > IP address authentication were a secure mechanism in the first place). This is what we have done in the short term, but the ISP can't actually guarantee that only our students will be able to come down the pipe with those IP numbers. (This isn't what the sales people said of course :-() > > Long term, I believe, that we need to have authentication systems > > (preferably kerberos) built in to all servers that are not wholely > > public. But this is not practical in the immediate future with the > > resources available so I am looking for an interim solution that can > > be put in place fairly quickly at moderate cost. > > Well, I'm not much of a fan of Kerberos. Unfortunately, it may be the > only coherent solution available in the near future. I seazed on Kerberos because we have another major project that will use DCE for access and authentication. > > My preference (i.e. pipe dream) is strong authentication AND > authorization via public key cryptography and directory services. I.E. > SSL/SKIP/AKA style session authentication with the public keys and > authorization information coming from a directory service such as LDAP. > It looks like the web browsers are heading that way pretty quickly. The > problem will be getting it into all of the other protocols. Well I'm very interested to here you say this. We went to a general blurb session with SUN last week and while most of was heavily favoured with coffee I did manage to ask about security issues. They reponded by suggesting that publick key approach might be viable. What worries me is the problem of key management, certification etc. Any way they promised to get back to me, it will be interesting to see what they come up with. (Sun are involve with a large (at least by our standards) project with our Social Welfare (i.e. Govt) Department that will involve access controls to all system for all employees anywhere in the country.) In my initial post I deliberately did not suggest possible solutions for fear of influencing responses. Since there have not been many responses I will expand on our thinking. We have investigated and rejected the idea of having a firewall that people coming in have to log into i.e. there would be two paths into the campus net, a direct one from the internet and one via the firewall. All the firewall solutions I could find were geared to having small number of users accessing from the out side and used expensive (relativley) technology to do the athentication or needed special software on the remote systems. Also they don't solve the basic problem that using IP numbers for authentication is a bad idea. (Even if we have a screened DMZ) I have also looked at DCE based systems but while these will apparently do what we want they need a 3MB of memory on the remote system. The more we look at it the more it seems that the only sensible solution is to go with a public key system as David suggests, but this looks rather like the bleeding edge to me. David, (or anyone else) do you have any good references on SKIP et al? I know about the Netscape white paper on authentication. I was surprised by the lack of response, does this mean that these are not issues that are relevant to other academic institutions or does it mean that they are in the to hard basket? Cheers, Russell