Oct 28 - Nov 1, 1996
PPPL
This was basically three meetings in one. The first was to lok at how ESnet should implement a Public Key Infrastructure. The second was to look at the DOE ER network (ESnet) today and in the future, and the third was to look at various initiatives in the distributed collaborative environment. A major theme throughout all three meetings was security, at least 30 percent of the time was spent on security related issues such as PKI, Kerberos/DCE. There was also a lot of discussion on DOE2000. The meeting room was wired for 10 Mbps Ethernet, and > 20 percent of the attendees had laptops that were plugged in and in use to take notes during the talks. There were many items of direct interest to SLAC in the near future, I have highlighted particular ones in the Table of Content above.
NIST working with NSA to spearhead federal PKI efforts. There is a steering committee. DOE is represented thru Tom Rowlett's office. Encouraging interactions with universities. Hopes for a world wide PKI. Working groups will forward recommendations to a federal steering committee. DOE PKI must include wide representation, must be interoperable with commercial and academia, must be cost effective. Partnering with some other agencies, and others are looking at peering. Being watched by other areas of the government.
The DOE CIO (Chief Information Officer) has been established. He is Woody Hall and he has has heavy responsibilities. Funding limited since not a programmatic function. Want to eliminate duplicate work, incorporate new initiatives into department's activities. They (DOE/CIO) believe there should be a singular PCA (Primary Certification Authority) for the DOE (but may not include M&O contractors - hopefully not since I do not see all of SLAC's collaborators worldwide agreeing on a single PCA) with multiple CAs (Certification Authorities) under it, but unclear where PCA will reside. Put together a database of activities occurring in non-classified areas. National Security Conference number 19 was at Baltimore last week. Expect federal government will eventually get out of cryptography business. Recovery of data is a big legal issue (possibly under warrant conditions) which may have constitutional ramifications. There are also liability issues, e.g. of CA to community. Big issue is communication and education of the community.
Aiken & Tommy Thomas felt a single PCA will not work, there will need to be multiple PCAs which interwork, so the interworking will become a big issue.
Banking community has had strong key escrow in place for a long time, but they manage it themselves. On the other hand the banks are very concerned about sharing their escrow is the same as sharing information, and they equate it to espionage. A view of PCAs is that all they do is to provide information on the policies of the CAs beneath it, so that a user seeing a key from "joe" will know what trust to put in this based on the advertised policies. Sibert pointed out that the Labs are only about 1/6 of the total DOE. A question was raised as to how encryption and PKI will work in an international environment.
Special interest in remote instrument operation. Does the person who walks up have the appropriate requirements to run the instrument. Need access to remote resources for monitoring control, manipulation of data which requires that security and access controls be in place. Needs an architecture that is flexible, effective, easily deployed, and easy to use.
Security model drives the architecture, which is also being supported by the infrastructure, and operations to make it all work. Operationally must minimize the intrusive and administrative impact of the security environment. Operations must be integrated with the computing system administration. CAs represent the root of organizational authority and to sign certificates for people/sub organizations. In the absence of a common point of trust then a pair wise trust relationship can be established by a secure out of band mechanism. Use is decentralized, i.e. the people doing the work/controlling resources have authority delegated from the next level up etc. The root level only signs a few things, but does not abrogate institutional authority/responsibility. Some security systems must be "broken" under certain circumstances, e.g. an emergency medical situation. It turns out that the model is similar to that being followed by the banking industry.
Nortel was an original public key partner licensee, with over 15 yr. experience. Entrust is a family of standards based software security products. Entrust manager, directory, client, toolkit (also an Entrust/lite). Entrust manager looks after keys. There are 3 types of admins, policy level, day to day operations, adding/deleting people. Directory keeps track of things. Two variants of toolkit, one for store and forward applications, the other for online transaction processing. Easy to use, hide complexities, no admin overhead. The APIs are public domain. Entrust engine runs in clients. Will work with PKCS#11 but also works with other tokens. Entrust security kernel is validated to FIPS 140-1 (first & only product validated so far). It is algorithm independent i.e. have licensed patent and done their own implementation of RSA, as opposed to having licensed the implementation. Applications include: email, eforms, paperless workflow... Entrust aware vendors include Qualcomm (developer of Eudora), Symantec, HP, Stac and about 8 others. OEM partners include Microsoft, e.g. Exchange incorporates Entrust technology, IBM is another.
Key management is the most difficult security problem. Issues include generating keys, keeping backup keys, dealing with compromised keys, changing keys ...Large scale key management includes establishing & maintaining 3rd party trust and corporate control of information, it also has to be easy to use. Goal is to establish and maintain trust over time. without burdening users, transparency is critical or users will avoid using it.
Key lifecycle management includes generating keys, issuing keys, using certificates, validating keys, keys have to expire and be updated. Key generation requires safe storage (i.e. prevent unauthorized access to private keys, backup (for loss) and non-repudiation. Every user needs 2 key pairs, one for signing the other for encryption. Nortel support key storage is done via a PCMCIA security token, smart cards or even a floppy disk, with secure software profiles; key backup, and 2 key pairs. Certificate issuance & initialization in Entrust includes admins provide users with initial authentication information; Entrust/manager securely downloads encryption key pair to client. Access to public key certificates requires a scaleable directory system, certificate revocation (done by Authority Revocation List (ARL)), key recovery ... Entrust uses LDAP to provide access to X.500 directories. Scaleable certification , revocation done by certificate revocation list (CRL) a secure list of revoked certificate serial numbers, The CRLs are stored in directory. Cross- certification extends 3rd party trust among CA domains. Can create hierarchies and "rooted" trust (but not required or suitable in most cases). Key expiry & update uses expiry dates defined in certificates, the key update is automatic & transparent. They also keep a key history to decrypt data with "old" key pairs. The expiry dates are defined on a per user basis. Can have different rules for signing and encryption key pairs. Entrust works on Windows, Mac, UNIX and has transparent interworking.
Electronic commerce has different meanings to different people. Includes pre- & post- transaction processes. Web is good for low dollar transactions, someone else holds liability. Web is not a PKI, it is a single application, no revocation system, only one-time transactions, cross-certification is meaningless (user centric certification). User centric certification uses CA public keys which are insecure (e.g. hard coded in browser/servers or selected by users at run time), cross-certification is meaningless, revocation is not automatic, password are not required to protect private key ..., no validation of software (e.g. FIPS 140-1, n.b. to go above level 1 (e.g. to FIPS 140-2) needs more than software, e.g. a hardware token), performance may be poor. Do you want to entrust every Verisign signed certificate (if not then lots of work to be done, more work than running own CA)?
SET (secure Electronic Transactions) is designed for secure credit card purchases over internet. Protocol defines all aspects between user & merchant, merchant & merchant CA, merchant CA and root CA, between merchant bank & Banknet, Driven by Visa and MasterCard. It is very complex.
Canadian gov. PKI is very advanced. UK has a technology demonstration program for MoD, Includes Nortel, Microsoft, Novell, Digital, EDS. Began in 1995. Goal is to provide secure interoperability of major apps.
Nortel has made an attractive limited term offer for their Entrust products for the DOE community.
Several parts of the US Electrical Power Industry is creating a system for reservation of electrical power securely over the web. It uses a single CA. $5.4B in cost savings. Will provide a single password for power traders with high-end Web security system to replace bulletin boards. TradeWare won bid and is using Entrust aware software.
Verisign & USPS are certificate issuers (issuing is only a small portion of the lifecycle of key pairs). USPS will be offering a time service in 1997, it is an analogy with time stamping an envelope to say what was in it at a particular time when it entered the system. The only vendor providing such a time service today is Surety. With Verisign and the USPS, it is difficult to check revocation status, and is difficult to establish and maintain a domain of trusted users.
DOE has a TravelManager project. It is on the leading edge . Cross-certification established among various DOE National Labs in US.
11 Sites each put in to buy Entrust software plus local effort to put up the Entrust software with applications.
AM-NII = Advanced Manufacturing - National Information Infrastructure project. See http://www-local.pppl.gov/~sdavis/doe_pki_esnet.html. They have had a year experience in running a CA. Deliverable is a scaleable infrastructure to facilitate the exchange of authenticated and secure unclassified & classified information between participant sites. Have purchased Entrust, LLNL & LANL have cross certified.
Deliverable: A scaleable infrastructure that will facilitate the exchange of authenticated and secure unclassified and classified information between participant sites electronically from desktop to desktop.
Original Participants: Allied Signal, LANL, LLNL, Sandia, and Y12
New Participants/Observers: ESnet, LBL, PNNL, and Pantex.
Agreed to purchase Entrust from Nortel as our PKI software
Convened a working group comprised of above participant sites to:
Formulate guidelines for the operation of a Certificate Authority
Request for fixes and product enhancements
Non disclosure sharing of coming products/features
Established and operate CA based upon above agreed guidance. Plus:
Purchased Entrust to establish a classified CA
Will use all unclassified work-to-date as starting point
Currently awaiting approval of Security Plan
3 Projects have been defined:
Purchased Entrust May 1996 for Solaris including Entrust 2.0 server/manager/X.500 directory with 50 user licenses.
Pilot mode includes server in office, users (friends) = 8, licenses = 550 (end of year money), cross certified with LLNL, Allied Signal cross certification planned (Nov 4, 1996), NASA cross-certification pending.
Goal is a production LANL CA & PKI system. What is a production CA, how do we get there, what do we need? His definition of a PKI contains 3 components: Policy & procedures, applications, encryption/key technology.
Proposes setting up a DOE CA Network master policy for setting up CAs.
There needs to be a recognition of affinity groups (e.g. HEP, manufacturing) which cross-cut organizational boundaries such as DOE. There are also international issues due to export restrictions etc. LLNL have been working on Web form authentication issues and tried with little success to extend to Oracle version 4.
Coordination between Entrust database & corporate database. Need assurance of accurate, current personal and corporate information. Need to keep current with changes, hire, renaming, former employees. Need to incorporate the contractor database and link with corporate systems for billing, tracking. Thus need tight relationship with the corporate database folks.
X.500 is a big job. Developing expertise takes months, optimal database structure is yet to be found, updating is problematical, database has to be internet accessible for other sites, good unique personal identifiers (such as an Social Security Number) may be sensitive (they use unique email usernames (without @node), which means they do not reuse email usernames).
People with similar names: need to be able to pinpoint say John Smith long after he has
retired and organizations change.
Sometimes it is important to know identity, others one needs to know the person's authorization (e.g. is she authorized to sign this PO).
Archives are essential. May not have master key so old encryption keys must be available and old signature keys may even be a court issue. May need to re-activate a key in order to decrypt something.
Acceptance is critical. Thus ease of use is important, as is easy installation, minimal conflict with other software, integration with other software, need to support user platform, and may need an internal training course plus hand-holding.
Emergency access to data may be critical. Managers may want & insist to share keys BUT it gives complete access to everything. Built-in mechanisms are meant for permanent access, e.g. have to delegate formally and then take back and these may be non-trivial processes. Suggestion is to appoint a proxy in case of absences so CA know who to go to.
Laundry list: secure location for key manager workstation; good people to manage keys; X.500 outside firewall; integration with corporate database; training in how to use (e.g. checking signatures, or when to encrypt, when to sign, or whether to do both) -- there are no local courses currently (e.g. at community college) so probably have to provide locally; consulting; installation of software / delivery of initial key; X.500 maintenance; protected, separate archive location; permanently unique public personal identifiers; names people can identify now and much later; crucial to have really good software -- security, $$$, acceptance.
Other issues: integration with DCE, Kerberos, WinNT, Netscape; good authorization infrastructure; multiple certificates (can one afford other infrastructures); levels of trust (solid vs. broad); toolkits; encrypted links to servers; integration with legacy software; buying keys (explain advantages, people expect to receive in a box).
Selecting target application for digital signature. Currently requires human signature, currently paper driven, limited risk, cross division/area and across Labs. Replace manual system & speed it up. Used ICO, used to take 4 days, now 4 hours or less. Challenges: guiding users from the familiar to the unknown; easy to use complete solutions; bridging the audit gap (paper pacifier, e.g. enable print out of statistics of transaction to allow user to sign and keep); setting up stable, long-term archiving for electronic records; allow multiple signatures on a document; cross-certifying; X.500 (DAP/DSP requires OSI stack, firewall problems); non X.500 alternatives? Unlike a written signature, a digital signature is not a universal signature today.
Potential solutions: work with vendors to add enhancements to products; DOE influence vendors to develop interoperable solutions.
Pilots are continuing at the various sites such as Allied Signal, LLNL, LANL, SNL.
Plan 39 is a DOE initiative to re-engineer DOE. Seventeen proposals put in for Plan 39 money. Four were from MICS (i.e. ER/ESnet). Total asked for was $18M. None funded. The current AM-NII was funded by MICS from available moneys. Now have 18 Plan 39 proposals. Requests reformatted, Woody Hall will review Nov 19, and hope to got forward for 1998 funding. All proposals should be on the Web in December.
Task Force writing a MOU on Key Distribution Center (KDC) management. Basically define trust relationships witching symmetric key technology using Kerberos and DCE. This is needed for cross-cell authentication since one wants one document that all sites can agree too, rather than n**2 cross site agreements.
Started from DOE orders since all sites know them. From this they developed an itemized list that is concrete enough to be automatable, and precise enough to do a risk assessment. Original described Fall 1995, version 1 sent to DCE working group on May 8, 1996. It was put on the Web but hidden behind a DCE password.
Bulk of 52 requirements are operational, many are just ordinary good practices, but have defined 3 attributes (DCE groups): US citizens, Employees, Verified. Some sites have initiated a technical review. Have begun comparison with CA and non-CA operation rules. Want all DCE cell managers to begin technical implementation where possible. Must have a Kerberos 5 implementation, so AFS cells probably cannot participate. DCE cell managers must verify technical feasibility, and policy issues should be raised with local CPPM.
Other issues include: comments on desktop management; does DOE badge structure work for us; open up for more public discussion.
Levels of assurance include levels of trust in certificates and levels of badges. Uses include: authorization, agreements, FYI, need to know. Current policy structure: every site provides a representative, agree on an operational plan, similar to peer-level group (as opposed to a hierarchical structure with a single top level PCA) used by banking industry, limit liability.
Certificate authorities:
Require policy and operational audits. Key management services includes: updating master keys, key lengths, DSS, DES, archiving, ... X.500 directory services are required and uses will be as in Entrust. Want someone else to manage X.500 for you since it is complex. Need written password procedures. PKI technologies need to be interoperable, vendor independent open APIs, single vendor not desirable, FIPS 140 compliant, standards. Physical proximity is important, e.g. for emergency key revocation, "closed for weekend" may be unacceptable.
Acknowledgment form says users understands about export control, business use only, revoke if disclosed.
PKI can have multiple levels of key with different levels of trust. This is different from the Kerberos world of either you have a key or do not.
Possible initial application is Email / Document distribution lists. Start by CA & KDC managers using Entrust enabled email. Then extend for ESnet site contacts, CPPMs, Lab directors, Secretary. All these people have expressed needs for some secure distribution mechanisms. This application would help market the ideas. Sites not running a CA might use the ESnet PCA to enable a few users at that site. When bringing on less computer tolerant people, one has to be careful about document formats, especially since decrypting it and then sending it elsewhere (in decrypted form) to be reformatted may break the security model.
Clem Boston of CDSI works for Sharon Shank of DOE as a DOE contractor. Defining PKI and products requires broad input to understand the requirements. Go head for a PKI since it is policy will need to come from the DOE/CIO. Other agencies are watching the DOE in particular its TravelManager program. PKI = Infrastructure supporting the public key cryptography. The PKI working group does not include Digital Signature (DS). DS is a separate working group. Both working groups will report back to the same steering committee. If implement the program may reduce some of the liabilities of the contractors. There is a working group of 18 people from about 9 sites looking at PKI for DOE.
Phil Sibert (DOE) said the DS working group is more oriented to applications, DS is recognized as probably the most important short term application.
Bill Johnston pointed out that PKI is still evolving, it is still being defined with guidelines etc. being developed. It may be unrealistic to promulgate guidelines until we have more experience in running a PKI. It is similar to where we were with running a DNS about 10 years ago. The ESnet PKI task force recognizes the activities will be longer term and will need a working group. The suggestion is to start out a PKI Task Force and will build on the AM-NII work, to be chaired by John Long.
Alan Sturtevant reported on time scales for KDC. The cell is operational, the server will be moved to a securer environment. Also need John Volmer's document (on KDC management) to be blessed by the ESSC. Will also need DCCC representatives from each site. There may be a need to audit new sites joining.
The ESnet CA will need a document to define how it will be managed. Hope to have a pilot phase 1 with a straw document by Jan-97 with some sites using, and some cross-signing going on.
Will need the KDC and CA management documents to be reasonably aligned,
this will probably occur naturally since it is the same people running
the CAs and the KDCs. It is however, probably realistic that we will have
both Kerberos (symmetric keys) and private/public keys (asymmetric) .
NERSC/ESnet moved from LLNL to LBNL (complete Oct '22 96). Working on various strategy documents. Strategic plan (late CY 96 draft ready). International connectivity report due late CY '96. There is a Progress Report being put together by Roy Whitney due early CY '97. Video support re-evaluation due mid CY '97. The Program Plan being put together by Lester Welch is due mid CY '97 and a Program Review due mid CY '98.
Budget is flat for '97, for '98 too soon to tell, expect to be flat. FY 97 budget is $4.9M ESnet ops, ESnet ATM $6.15M, ESnet video $0.270M, ESCC/ESSC $0.3M, detailees/CIAC $0.54M... FY97 got $14.6M. Has been flat for last 4 years.
Significant savings thru using ATM allows connecting extra sites at N*T1. DOE2000 is significant effort in DOE. Joint effort with the Defence Program (DP). Stu Loken and Jim McGraw added to MICS staff on interim basis for DOE2000 efforts. At the moment have $8.5M hope to be available Jan 97. $2.5M on Advanced Comutational Testing & Simulation. $3.5M on Collaboratory R&D. Workshop in Reston Nov 12, 13.
Plan 39 investment fund had 4 MICS (17 from DOE) proposals submitted last year. Congress did not approve. Proposals reformatted will be prioritized and submitted for FY98 budget.
FNC: White House to NSTC to CCIC to Large Scale Networking (LNC) and the FNC Villesenor & George Strawn co-chair. Under FNC there is a privacy & security working group (PSWG) and EOWG. FNC has an Advisory Committee (FNCAC) to address broad spectrum of issues that ESnet should address.
Next generation Internet = 100 sites at 100 times today's (today equates to T1) speed, plus 10 sites at 1000 times today's speed, recently announced by Clinton with $100M for 1 year (hope for continued funding for 4 more years at similar level, i.e. a total of $500M for 5 years). Participants DOE/NASA/DOD/NSF. There is a draft action plan. Hope to have finalized very soon then goes up chain to White House. Hope for funding for FY97. The $100M is not a tax on the current networking program. It is to go on network infrastructure.
Issues for '98: ESnet international, ESnet high speed to universities, follow on Sprint contract, DOE2000 implementation, evolution of HPCC, continue reorientation of technology research towards science (as opposed to research for research sake, i.e. more for applications in use of the technology research), impact of next generation Internet, award of DICCE add-on proposals.
Need a task force to look at community needs for video conferencing. Probably a different group from the RCWG since they have a vested interest to keep going. Want a recommendation to go to HQ in the coming year.
This is a proposal for a new structure for the ESCC/DCCC to make the forma l structure better match the actual. There are site cotacts, but people vote more with their feet, i.e. by attending and participating. Proposal reorganizes ESCC/DCCC into 1 committee with series of working groups (WGs) and task forces (TFs). The old ESCC will be the networking Working Group (WG) with subgroups such as NMTF, IPngWG. Other WGs include the Video/Remote conferencing WG. The current RCWG would comprise the group i.e. based on active participants. Other groups include: E-Mail Task Force (TF), Group Communications WG. The DCE/AFS might have a site member. The PKI infrastructure will come out of the current KDTF and may need site reps. Apps WG is whomever is interested. Maybe new WG & TFs in areas such as CORBA, Java, graphics, electronic notebooks, distributed computing algorithms etc.
Any new ESCC generated funding proposals would be in the style of recent Plan 39 Reengineering efforts for a DOE wide file system and a start up PKI. Plan 39 is oriented to providing infrastructure support. The new ESCC will track the various R&D projects, participate in pilots when they require ESnet infrastructure & in conjunction with ESnet management, bring systems into production.
So the proposal is to merge the ESCC & DCCC with TF & WG to provide site-specific & other related infrastructure for the distributed computing and collaborative environment including networking. It is currently called the "New ESCC". Members are all the participants from all the WGs and TFs, i.e. those who shows up. This is not much of a change since there are hardly any issues that go to vote. It is pretty much a recognition of how things are running, so rather than vote it was declared a victory. A proposed charter of the New ESCC will be presented at the next ESSC meeting Jan 7-9 1997 in DC area.
Looks after energy reserves among other things. Includes oil & gas, coal, nuclear, electric & alternative fuels. They do analysis, system design and support, look at energy markets, end uses, do forecasting, quality assurance and standards. There is also an Information Technology division. Paul is in hardware software group and designs networks.
Token ring 16Mbps, IBM 3090/400, some FDDI and Cisco 7000 routers. Have hyperchannel. Need 3090 to print on an IBM 3800. Has T3 link to ESnet. Is in Forrestal building. Major apps are Electronic Data Management System (EDMS), Electronic Data Collections, Electronic Data Dissemination.
Reengineering (down sizing) reduce to 335 FTEs by yr. 2000, eliminate main-frame by 1998, move all applications to LAN and Unix, continue use of Internet as vehicle to disseminate information.
May '96 CEBAF commissioning, Jlab.gov not permitted by FNC & jlab.doe.gov is not appropriate. Site was anxious to order new stationary. Sep-96 jlab.org announced email works via alias to user@jlab.org using redirects from user@cebaf.gov. Telnet host.jlab.org works because re-evaluated during DNS lookup. Email to user@host.jlab.org does NOT work (arrives at host which does not know how to address it).
Reactions: some staff members do not like ".org" (are we less a National Lab, less recognizable etc.? Some members do like .org (may facilitate communications with some funding sources), DOE site office would like to have their systems addressed as .gov. May affect discounts Computer staff: "a nightmare to implement".
Plan for full implementation has a site task force consisting of major computer groups to decide how to implement. Probably less of a problem than for some sites since Jlab is small, small number of groups managing systems, widespread use of central mail server, PC/Macs not a problem (just announce the day). Workstations and UNIX users are more of a problem, needs reconfiguring network on the host, sendmail, change in outgoing email addressing, NFS mounts etc. educating users of .rhosts file. Dual name servers, but individual host can only know itself as one name. Cannot do in one fell-swoop.
ESnet now has direct connection to regionals which reduces need to traverse the Internet. People are beginning to do peering avoiding the NAPs. If people leave ESnet to move to an ISP with supposedly better service, then ESnet will start to fold. So we must keep ESnet service QoS better, i.e. keep it moving forward, and be able to measure and benchmark so we know how good it has been and how it's likely to get.
Marv Christensen left to join IBM. A large number of issues are a result of exploiting known vulnerabilities easily secured by patches. Very few incidents exploit unknown vulnerabilities. Sites with problems are those without resources to install patches. Over half of contacts deal with viruses, PC viruses are the most common, huge increase of macro viruses (ciac.llnl.gov/ciac/CIACVirusDataBase.html). Increase in Sniffer incidents.
There is a windows version of ssh (the secure shell) is now commercially available & a Mac version is to be released soon. Ssh is becoming more widely used at DOE sites. More hackers are starting to use ssh to hide their tracks.
Sniffers are most common way to capture passwords. Install sniffer detectors on all hosts, run NID on as many nets as possible especially on border nets.
FIRST has been seeing increase in IP spoofing attacks. Configure routers such that source routed packets are not allowed, replace r services with ssh, if use r-services at least avoid .rhosts.
Trojan programs are more widely used by hackers. Rootkit replaces ls, ps, & df to hide tracks, Secure system and keep patched.
NID = Network Intrusion Detection tool. It's a passive tools (intruder does not know network is being monitored). Can recreate connections down to keystroke level. Can perfume threat analysis during or after data collection. No modifications to hosts it protects, Can start collecting on detection of intrusion.
Argentine hacker tracked by Navy in government nets. Traced to university net. NID full-scale monitoring illegal. In response LLNL developed iWatch when a specific signature seen save short character context. Privacy issues.
SSDS allows an automated means to rapidly distribute & install software security patches on a large number of networked computers. Reduces time & effort to install patches and keeps system at uniformly current level. Automate notify of new patches, determine applicability, install, back-out etc. Monitors vendor's sites for the latest patches & store in a non-vendor specific format. Evaluate untrusted target systems on a scheduled basis & install patches as needed. Will be looking for volunteers for beta testing.
SPI-net is a distributed security inspection product for networks of Unix and VMS systems.
AIS alarms is a secure backbone for a collection of tools that actively search out, passively trap, and react to intruders on the network accessible hosts.
Number of calls to CIAC is reducing but not going away. Big challenge to keep on top of new cracker tools being used. Number of vendor patches is increasing. Sun is working on improving the installability of the patches. CIAC has a Windows 95 system so they are becoming more familiar with that.
CIAC got a budget cut. It is about $1.2M/year. 25% from ER, NM did not increase, minor $ dollar reduction, but costs go up, and effectively lost about 0.5 FTE. NIST put up a proposal for CIAC/CERT to put up a similar service to the service they provide to ER to other arms of the government. Then other government organizations/agencies would subscribe to CIAC/CERT services. The proposal puts up seed money which is to be paid back in subscriptions later. New ruling coming down that says agencies must have an incident response plan. If the agency is small enough then may want to subscribe to CIAC/CERT.
Integration of ATM: At first connected the Ciscos to ADSUs, then replaced with Cisco AIP cards, now four sites have a Fore ATM switch. Have 2 OC3 ports, 10 ATM ports, 2 NAP connections (Sprint NA @ 4.6Mbps/ATM) Fix-W @ 4.6 Mbps/ATM). LLNL, ANL, LBNL OC3 native ATM. SLAC initiated to go to T3/ATM. LBNL testbed link @ OC12c/ATM. KEK going to 1Mbps FR (not ATM). ORNL @ T3/native ATM. ESCC supports conference hook-ups including DOE-2000, SC96. Conference support is very labor intensive.
Successfully survived period of general chaos on internet. Rich interconnection to NAPs, MAE-E/W, Fix E/W, regional network connects. Move to ATM with Virtual Private Networks (VPN). ESnet "boringly reliable and predictable" - Les Cottrell.
International congestion controlled by bandwidth reservation. Creates complaints about ESnet congestion for non-ESnet traffic. Additional capacity installed by Germany, Italy & CERN helped offload shared links. Statistics show international links heavily loaded but not saturated.
Transatlantic ATM Pilot originated with request for interest from Sprint. DFN identified as best initial collaborator. Japan very interested,
SecureNet project to support classified end-to-end encrypted data at T1. Plans for T3 native ATM by Fall '96 and OC3c by early '97. Community LANL, LLNL, Sandia/CA/NM (T3-OC3); Allied Signal, Pantex ... (at T1), ORNL soon.
Video conferencing (VCS) is heavily used, expanding to 40 port PictureTel MCU. Reservations thru the web.
Move to LBNL added a telecommute work center (TWC) at Livermore (very successful), ESnet office wing at LBNL, Network Management Operation Center (NOC) at LBNL. Developed distributed office concept: web based pager, web based personnel locator, home based Video Conferencing (VC), combined with alpha skypage, cell phones, TWC etc.
New backbone architecture with more ATM focus being migrated to. Beginning a market survey for Sprint contract replacement (expires Fall 1999, so need new contract Fall 1998, so RFP in early 1998, so procurement package need late 1997, so need market survey now). Will use a hubbing arrangement in some area such as Bay Area sharing an OC3 port into Sprint ATM cloud. In some cases will have an ATM switch on site, and others will have a T3 connection to a router. Also architecture provide backup connections. The architecture scales (in number of nodes), it is easily modified, and simplifies the routing. Expect to replace most of the FTS-2000 T1 circuits with N*T1 access & FR backup.
New contract will support multiple services including future services), collaborative mode, emphasize leading edge technology, 5-year with options to extend, include CPE, and hope for "aggressive pricing".
Video conferencing: they are looking at distributed Multiple Connection Units (MCUs) (including international), do Constant Bit Rate (CBR) over ATM, better testing/qualification of users, merge room-based & desk-top based; get home/TWC/LBNL VC for staff operational and make available to community.
Advanced Test Link (ATL) OC12 initially, establishing a R&D agenda.
Lot of work on resolving NAP/MAE/FIX peering arrangements (FIX-E going away).
Enhance ESnet web presence. Video of large science projects.
Traffic growth slowed may have leveled off, DECnet traffic gone down.
NSF/vBNS connections program, 14 sites being added, another 30 sites being reviewed, more to follow next year. Many new types of applications in addition to supercomputer only applications. vBNS being connected to other hi-perf research nets (e.g. DARPA, Energy NASA). Being "hardened" i.e. more production emphasis. Will go to OC12.
NAPs (Networek Access Points) have worked out as an interconnection strategy. Inter university traffic is only 15% so improved inter university links (e.g. Internet II) might not help unless other networks agree to interconnect.
Internet II consortium of 35 universities to construct next generation Internet. Press release, probably paired with vBNS connection program, also a likely candidate for funding under Clinton's large scale networking initiative. Has support from commercial vendors.
Clinton initiative OC3-OC12 range. Funding $100M by reallocation of defense & domestic technology programs. DOE expected to be involved.
DOE/ER funded for DOE2000 initiative. FY97 funds ~$8.7M. Proposing a distributed help desk pilot.
NASA most networking consolidated & moved to Huntsville, most of Ames/NSI folks are gone. Announcement NASA will use Sprint ATM under FTS2000 contract. This has been over-ridden and back working with AT&T. DoD DREN contract awarded to AT&T for interconnect services including ATM.
KEK (512kbps), JAERI (128kps), NIFS (64kbps) into Bay Area MAE. Running at 30% capacity. All 3 of the Japanese lines are candidates for upgrades using frame relay (at least double).
Germany has 2 links, Garching (has recently been terminated) and DFN (Deutsche Forschungs Network) has a T1 into Duesseldorf. It is running at ~50% capacity, but holding steady since other German links are taking traffic that used to flow over ESnet.
Italian traffic has also been off loaded (by a pair of T1s into West Orange MCI POP) and now the ESnet link looks lightly loaded. INFN plans to get a big link to DFN so they can tride on the DFN links to the US (see below). DANTE is also planning on showing up at the DFN but no date has been set yet. INFN prices for 45Mbps comparable now with US costs.
DFN has deployed an ATM backbone network. Initial service at 34Mbps & plan to extend to ~70 sites by year-end. Service is Constant Bit Rate (CBR) (vs. Variable Bit Rate (VBR) used by ESnet) i.e. very conservative. Currently only support IP. DFN pricing was very good (from Deutsche TElecom (DT)) for 34Mbps site access ~$330k/yr. (equivalent to US costs), subsidized, without subsidy is double US costs. DFN funded at $57M/yr. for 1996.
DFN plans install transatlantic 2*T3 to terminate in DC MCI POP. Schedule Dec '96-Jan '97. Will connect to MCI, will include IP connect to DFN also INFN & DANTE (details on INFN & DANTE vague, but it is expected to result in extra bandwidth on the DFN links to accomodate the extra traffic), likely will be charge for guaranteed bandwidth. ESnet interconnect under consideration. but MCI less than excited about ESnet collocation. Unclear how DFN will charge for use. Links will use ATM switches on each end to allocate bandwidth with possibilities of early ATM interconnects for IP traffic.
"Where Wizards Stay up Late" new book on the origins of the Internet.
Central message is that the ESCC/DCCC are crucial for success of ESnet! The creation of the ESCC and its WG/TFs has been a great success. Need to keep up good work and work together more closely with the ESSC. ESSC's big job is feeding requirements into the system, so it is composed mainly of program reps who are mostly active researchers together with providers (DOE & ESnet).
ESSC concerns: university access, performance management, international links, research network, bandwidth upgrades, distributed computing, creation/updating the Strategic Plan.
Plans for the coming year include: developing the collaboratory projects/pilots (such as support for distributed computing tools) to understand issues especially the resources needed to bring to production state; creating a program plan, coming up with a progress report, work on improving university access, and planning the next ESnet review.
Issues: interaction between ESSC & ESCC, ESCC reports should be a bigger part of the ESSC meeting with wider participation (e.g. WG/TF chairs report on their activities); need to decide on the right balance between the production network and experimentation; relationship between ESnet and Internet II, DOE-2000.
Next ESSC meeting Jan 7-9 DC will be to a large extent devoted to prioritization. Comments to lprice@anl.gov, essc@es.net.
Enhancing service availability with UPS, redundancy etc. All servers moved to LBNL, new hardware ordered & delivered to LBNL. Now using ssh with encrypted sessions to access all ESnet service machines for support purposes. ESnet gopher service now removed can use http://www.es.net/gopher instead.
The Video Conferencing Service (VCS) awaits facility completion at LBNL. Need PRI & modem lines to be relocated, rack space has to be prepared & stabilized. New PictureTel Montage 40 port H.221 MCU has been received. Teleos 200 & Teleos 60 have had upgrades ordered. Install Teleos 60 Nov 18, MCU Nov 25. MCU numbers will change. VCSS (VCS Scheduling Service) changes required for new hardware so a dedicated database machine has been purchased. The Vtel MCU will be moved to the Livermore TWC. Three PRI to home users.
To provide production quality support for DOE-2000 collaboratory environments. How to evolve distributed computing pilot projects into a production service with a quality support infrastructure. An example of something in an early research state is a PKI today which is at research status; this will need to move to a pilot state i.e. it is deployed, MBONE or DCE are in this state; the next step is to use for a collaboration, for example the ESnet backbone service and VCS are at this stage (needs to be boringly reliable); the final step is to use a commercial implementation of the service (e.g. an ISP to provide Internet access). The latter two levels can be considered production, the first 2 are more at the research level.
All help desks must move from research/pilot status to collaboratory state before it is production. A distributed help desk is composed of knowledgeable personnel at various involved sites and the ESnet help center AND possibly a well-known and (possibly) funded "service expert" within the ESnet community. The HelpDesk itself is a distributed service!
ESnet will be authoring a proposal by Jan 1997 requesting DOE2000 funding to investigate and develop the concept. The first pilot service requiring a collaboratory status HelpDesk is the ESnet portion of the MBONE. Now soliciting "interested parties" within the ESnet community to review / contribute to the proposal. Send email to aps@es.net if interested.
Tough issues: architecture, procedures, responsibilities (demarc ation points), cost estimates, locate service experts, require ESnet community wide involvement and commitment. ESnet central requires 3 FTEs worth of funding to "contract out" support from the various "Service Experts" within the ESnet community.
Most sites have agreed that the preferred method to receive email enclosures is MIME. A few sites need gateways so they can get from their enclosure method to MIME, and this hoped to be available soon. http://www-itg.lbl.gov/AWG.hm.pg.docs/e-mail.req.fm.html contains a long list of requirements/wishes. The most important areas are: a single email system/client for all platforms (there does not appear to be an acceptable solution to this yet); Web based; IMAP4; LDAP; MIME; easy digital signing, encryption, de-cryption etc.; and a bulk mail filter. Roy Whitney requested the ability to handle a large numbers of folders (e.g. hierarchical folders). Migration will be a big issue, e.g. converting existing folders and nicknames.
We can get email to people, we are getting better at binary exchanges, but still problems with reading the binary files. LLNL has 7K QuickMail & 2K using Eudora plus an unknown number using VMS & Unix based packages. QuickMail users use attachments without even thinking, and Unix/VMS users are often unable to deal with. Mail from other sites is even more difficult.
Compatibility server provides a profile for each user, which each user can customize to tell what platform, what apps are supported and if & how to do conversions. It supports Mac, PC & Unix. The mail systems supported are cc:Mail, QuickMail, Unix (sendmail) ...
Word processor formats acceptable are Fm 4,5 Word for windows 2.1, 6, 7, Word for Mac 5, 6 ... Excel 4, 5 for the Mac & PC, Lotus WK3, ASCII table (tab, CVS), Postscript to PDF ... You specify what you want to get back & if the Email contains an enclosure Clarity recognizes then it translates. LBNL has a translator machine where the email address specifies the output document format required (e.g. html-unix@polk.llnl.gov). It accepts various encoding. It can be used from other sites. Dave will explore getting the list of email address to converters made available via the ESnet Web pages.
Do not gang together multiple enclosures.
The next steps are to create a profile interface for all users. Preload those profiles that are known (QuickMail need Mac, MIME, Word, Excel, PICT). Modify central mailer sendmail to hand incoming email to compatibility server. There is a web user interface so users can customize their entry, this will need added fields for the compatibility server.
Have all hardware & software, need staff resources, hired additional help. Server can only translate to least common denominator. Translators are not perfect. Can't always get a translator that you want (e.g. PowerPoint to Persuasion). The cost of a Compatibility server is about $10K per server. See http://www.clarity.com for more information. Dave Osterman also noted that he has written code to convert QuickMail folders to Eudora folders and also the nicknames. Contact Dave if you are interested.
Bob is quite involved with this. Memory bandwidth of workstation ($10-20K) exploded, 1 yr. ago 20-25MB/s, now 130-200MB/s, routers have leaped from 100Kpps to 1Mpps range in last 2-3 yrs. So 10->100Mbps Ethernet not kept pace. So can we scale Ethernet to Gbps? Collision diameter shrinks again. Need to invent new signaling & coding, copper gets much harder (with UTP5). Is shared bus half duplex still needed (CSMA/CD) many think not, not so few think yes. Are bandwidth guarantees needed this time around, few think yes. Should packet sizes change, almost all think not. Coding system on wire will change. Decisions: do not mess with CSMA/CD add a few tricks to make at end office wiring distances, don't change packet sizes, use Fiber Channel Standard (FCS) with 8B/10B code on the wire and short wave length/long wave length fiber optics.
Collision diameter with CSMA/CD shared bus is a problem. Ethernet has ~2500m collision diameter ( at 10Mbps due to 64 byte minimum packet size). Fast Ethernet has an ~200m collision diameter. Gbit would only have 20M diameter. So extend the carrier event to 512 byte times (even for a 64 byte packet) so diameter is extended to ~200m (actually for fiber it could be as much as 400m). This is a heck of a neat hack. Then the problem is how much bandwidth is lost. Simulations show that one can extend Ethernet to ~500-600Mbps. Note that if one wants higher speeds then don't use the shared bus but go to Gbps Ethernet switching with full duplex.
The new signaling layer uses point-to-point with coding based on ANSI X3.230 FC-1 8B/10B. The non data space provides codes for error reporting (e.g. link not available). Automatic power on procedures and negotiation between nodes.
Copper is really tough this time. NB UTP5 is only specified up to 100Mbps, thus any design must stay under this limit. Thus complex constellation encoding is necessary & complex (i.e. costly) DSP must be used for equalization & echo/self-NEXT cancellation. Overall cost of copper interface needs to be less than for fiber interface. Cost for UTP Cat 5 4-pair office run is in $200-300 range in bulk ($300-400 in singles). A 2 multimode fiber office drop cost in $600-800 range (bulk).The difference has to do a lot with industry volumes and marketing, so fiber could get a lot closer to copper in cost. In which copper may not be prefered solution. Industry expects 2 years to decide on a solution and get into product.
Fiber can run 200m in 62.5 MMF(multi-mode fiber) & up to 450m in 50micron. For longer distance more expensive long wave length laser give 550-850m over both 50 & 62.5MMF, and 3000m over single mode. LBL did survey of distances between buildings and found that 500m does not meet many of the needs, so they are proposing to start installing single mode fibers. Note that LWL have a safety issue. HP has indicated work on shaped launch VCSEL into MMF may yield longer distances up to several km.
SLAC should look at including some single mode fibers in new between building pulls or any runs over 200m.
There is also talk of short haul copper for <= 30m for use in closet and machine room using twinax. Does not currently look very inter esting.
Timeline is to have products appearing April/May/June 1997. Nbase & 3COM already are pricing LAN switch ports at $2500 retail. Cisco routers ports might be $15-25K retail. Buffered FDX repeaters at $1K/port for 12 ports. NICs at $1500. Cost /
unit of performance 10Mb Ethernet = 32, 155 ATM = 24, FDDI = 18, 622 ATM =10, 100 E = 7, 1Gbps = 3. Bob has a PDF file which he will send out Email to ESCC. Doubt Catalyst 5000 has sufficient backplane bandwidth to support Gbps Ethernet. Could be the next nail in the ATM for the simple LAN backbone coffin.
Cisco has Ipv6 running, ESnet has its backbone running, 6bone activity being supported. Ipv6 standards have not changed much since last reported in May, except many solid parts have been thoroughly tested. RIPng ready to be deployed, IDRP may be far away. Scalability of Ipv6 routing still as much a problem as it is with IPv4. Address assignment still contentious & unresolved, i.e. provider-based addressing.
Testing at UNH interoperability #2, jun-96 was quite successful.
Non disclosure from Cisco. RIPng will be available for test Jan '97. IS-IS extensions for IPv5 will be available for test Jan-97. EIGRP extensions for Ipv6 available for test Mar-97. Eng. field trials (EFT) of IPv6 in Jan/Feb 97 (no other protocols in EFT release), Product beta ready for test in 2nd half 97 (probably in 11.4 (12.1) will include full IOS functionality). Current impediment is to get an ISP to commit their production net. IDRP vsn 2 viewed as work in progress, is tough to implement & 18 months away minimum & will still not solve staff & retrain / redeploy problems for ISPs. One very real answer is to do an integrated BGP4 (main protocol used between sites and providers) that support v4 AND v6, likely to be supported by ISPs, probably will be a fight at the IETF (will work this one in Dec).
For Information on 6bone see www-6bone.lbl.gov/6bone. It is in 10 countries, 4 router implementations, 8 workstation platforms.
Started IPv6 roll-out as 6bone participants. Running IPv6 over IPv4 tunnels using static configured tunnels and Ipv6 capable routers. Automatic tunnels are a non goal of the 6bone, this has been done before. Most 6bone participants are not ISPs. Looking for additional involvement of other ESnet sites.
Address structure has 128 bits where AS # (autonomous System #) & IPv4 network # are embedded with EtherID added at end. AS number in address gives AS # of ISP since AS #s are registered.
ESnet sites are KEK, FNAL, DFN, TWC, & ESnet. ESnet connects to Cisco.
There is a 6bone registry that each participant is required to register in. Info registered includes: tunnel endpoints, contacts, prefix, Ipv6 pingable hosts, remarks. See ftp.ripe.net/ipv6/lp6rr/ESNET. The first step for a new site is to connect one host to the 6bone via ESnet. A 2nd step might be to connect an Ipv6 LAN to the 6bone via an Ipv6 tunnel. The next goal is to go native IPv6 over ESnet. No router code available so using a DEC alpha as an IPv6 router.
Future stuff includes: more Ipv6 tunnels to ESnet connected sites. Ipv6 traceroute (any day now). Web server registry for new site tunnels. Native Ipv6 over ESnet backbone/sites. Ipv6 routing protocols.
John Saperia (ex DECmsu) has moved on and has a new statistics gathering system which ESnet are beta testing. Stanford is also using. Using Spectrum for real-time. Tools to monitor the state of connectivity to popular non-ESnet sites (suggestions welcome), Sue Smith has a Web interface. We (at least Connie & I) should pay them a visit.
Frame Relay/ATM gateway testing (it works but latency is bad). Testbed to LBL <-> Burlingame (OC3, OC12) policing, traffic shaping congestion behavior.
See draft-odell-8+8-00.txt Replaces the current flat 16byte Ipv6 address into tow 8 byte octets. Upper 8 bytes is Routing Goop, lower 8 bytes is end system designator (ESD). ESD is globally unique, a system need only examine ESD to determine if for that system. ESD designates interfaces on a system. Interfaces may have more than one ESD.
They support ISDN users via 3 PRI lines using Ascend routers. They evaluated Cisco's offerings but found them severely lacking in capability. He would like to move to Cisco, but is still waiting for the management facilities among other things. Since LBNL uses the Cisco proprietary EIGRP routing protocol which Ascend cannot support they use static routing for the Ascend router. They use a RADIUS server to provide authentication. The RADIUS server also provide connnection records which are used for billing.
FNAL had 4 older Combinet PRI routers since they got started early. They were much cheaper (about 4 times) than the current Cisco 4500 router offerings. One is used for on-site connections to outlying low use areas. They have avout 40-60 users. They do dail back and use the Connection manager. They do not do any charge back. It takes about 0.25 FTE to manage, the initial start up required more than 0.5 FTE. The remote units are also Cisco/Combinets which are password protected so the user is not allowed to re-configure the unit. They do not use FTS-2000 for their PRI lines since they were not allowed to make off net ISDN calls with FTS-2000 (i.e. cannot access a user's home). I have asked Janet to verfiy whether this is still the case before we get an FTS-2000 ISDN PRI line at SLAC.
LBNL uses Combinet PRI routers. They use dial back with the Connection
Manager package so they can use inter CO trunking to get cheaper calls
to outlying areas. They are concerned about Cisco's lack of support for
the Connection Manager and the older Combinet PRI router. They recently
evaluated a 4500 (I think Cisco lent them one for the evaluation) but the
lack of management facilities make it not viable for them at the moment.
Since they use dial back they can use their phone switch records to provide
billing.
What do we do/need to support collaboratories
Site Contact Participant
Networking Yes Yes
IPngWG Yes Yes
NetMon Yes Yes
DCE Yes Yes
DFS Yes Yes
AFS Yes Yes
KDC
PKI (PKI)
Email Need
One stop shopping, i.e. what does customer want to know and what is needed to runa collaboratory. I.e. it is not just a digital network connecting people.
Electronic Notebooks
Video Desktop
ISDN
EPICS
CODA
PVM
CPU connect
Lawyers
Directors
User Officers
Badging
E Pubs
MOUs
Collaborations
Facilities online
Identify Programs involved (e.g. how many programs are using EPICS)
Roy proposes that we start to gather this information and write up what these people do and where to/how to contact them. Much of the work is done, we need to take some credit and make the information generally available. The benefit would be to make information on collaboratory available online to the programs. Roy is willing to set up a Web site which provides a start to this, e.g. a Esnet Email page. Roy would send out requests for information. Roy believes this will help raise visibility and help in getting funding.
Types/Purposes of a notebook include: lab notebooks, design notebook, intrument log book, expmt log book, legal record (invention reports - intellectual property, sample tracking), notepad.
Sources of information: instruments, analysis/visualization/modelling software, individual researchers, groups (e.g. presentations).
There are two current views on electronics notebooks:Goals: help scientists make discoveries faster, help make better designs, find flaws earlier, improve efficiency, improve learning, distill knowledge more effectively.
Architecture requirements: cross platform, extensible including by user, configurable, multi levels of access at object evel, multi levels of sharing.
Recommendation: CORBA, Java (VRML), GUI - notebook engine - datastore.
Several prototypes were presented: LBNL (Sonia Sachs, Victor Markowitz) list/schema look, searchable, ORNL (Al Geist) looks like paper, sketch pad tool, PNNL (Jim Myers) Netscape browser based using CGI/Perl, Java, MIME helper apps.
Notebooks are far from mature, big steps needed in technology(screen real setate, readability, real estate), model to follow (e.g. paper replacement), better and common development tools etc. Lot of areas for collaborative development. Support/gain experience from DOE2000 projects.
Need to be able to define a policy and then be able to implement it for the enterprise, including customers. Clients (NetSeat) runs with a small security service applcation as a thin DCE client, the server is called WebStarter. Provides authentication & access control. Web server can proxy to other servers. The client talks the native protocol to the NetSeat which then talks a DCE secure RPC (or simply pass off as a native HTTP). Controls users ability to post read etc.
Another product is NetSeal provides distributed firewall functionality. Access controlled by IP address or user, security is centrally administered. It uses an ACL database and provides audit & logging. Access to the client or server is via an isecd that runs in the client & server. Between the client or server and the TCP protocol stack is a filter which makes decisions based on the ACL list. It provides end-to-end security for its services (ftp, telnet, nntp, X, nfs identofied by ports used. There is an ACL for each service to be protetcted. The ACLs are objects with inheritence. One can protect either the client or server or both.
Server runs on Sun/Solaris, HPUX, Digital & IBM coming. Clients are Windows 95 and NT. See http://www.dascom.com/ for more information.
Phase 1 had 6 sites, cost $600K. Phase 2 had an added 8 sites costs $650K. Phase 3 is to involve all DOE sites. They have applied for Plan 39 (re-engineering) funds. No funds available until FY98.
Running on six Sun Solaris systems now located at LBNL. Cell is available for production use. Cross-cells are installed for ANL, PNNL, SNL. SNL developed a cookbook procedure for adding cross-cell keys. Other sites may request cross cell keys. The DCE security server is the KDC for Kerberos 5 beta 7 applications such as Cross Cell Encrypted rlogin sessions.
Mike Weaver at DOE HQ is looking at WNT DCE & DFS clients. It is on hold awaiting newer versions of the clients. Tommy Thomas of ORNL is planning to test a DFS configuration with DFS servers at ORNL. Esnet DCE will provide DCE services. Doug Engert is using ANL, PNNL & Esnet to test Configured Authentication paths.
Esnet DCE will provide services for small test or pilot projects as needed. A limited number of user accounts and a limited amount of DFS space is available for test or pilot projects. Esnet DCE will serve as a eference Cell or Model for a suggested cell structure.
DCEWG Meeting 10/30/96, 20 attendees, 9 Labs, 2 vendors (Transarc & SGI). SGI will have a DCE 1.1 client for IRIX 6.2 in Dec-96, supports large filesystems and files. Transarc is coming out with products for non Unix platforms. There is a draft KDC security document, sites need to check the T&C's are implemented when configuring the cell. Also there is a DVE Trust-cell cookbook. They will start gathering DCE site info as a central repository (e.g. technical and emergency contacts).
Six sites have targetted to have production DCE cells. Identify and work with colaborators between these sites to exploit and demonstrate secure infrastructure. Need to move from pilot to production. Production includes: a recovery plan, working backup/restore. implemented Esnet KDC policy, qualified support & operations staff identified and published.
Open invitation to others to join. Enhance publicity efforts.
Transarc are introducing DFS-Light clients. The idea is to provide increased desktop coverage for DFS. Light refers to low cost both to buy software and to admibnistrate. Light clients have no additional requirements beyond those recommended for the operating system. The light DFS client does not require DCE at the desktop. There will (possibly are) DFS light clients for WNT, W95 and WFW. Light clients require a Light to DFS gateway. Gateway is a WNT machine running a DCE and DFS client , beta available December 96. DFS client talks to gateway thru SMB. Gateway talks to the DFS server via DCE/RPC.
Transarc has a DFS server Transarc forWinNT 3.51. It can serve Unix, WNT DFS clients, and DFS-Lite clients. It does not export the WNT file system. WNT 4.0 server due sometime next month
AFS client available from Transarc for WNT 3.51 now, They are working on a WNT 4.0 AFS client. The WNT AFS client is similar to UNIX clients in functionality. The commands are all GUI except fs: and include: klog, tokens, unlog, kpasswd, reconfigure. The WNT File manager can be used to examine and change ACLs and volume quotas.
Transarc also have DMAPI (for HSM and backup). The API defined by Data Management Interface Group which includes Auspex, Cheyenne, Emass, EMC, Hitachi, HP/Convex, IBM, Legato, OpenVision, SGI, SunSoft, Transarc, Veritas
DMAPI is implemented by the file system and used by the DM application to perform the following functions:
HPSS is the first application for DFS testing (1Q97). Other back-up and HSM products will follow later in 1997.
Locus also has a DFS & AFS client for Windows (not sure what versions, I saw W95 demoed, and WNT & WFW are or will be available). The cost is about $150 list in quantity 1. They are also working on a Mac version.
This is part of a DOE2000 proposal from LBNL. See http://www-itg.lbl.gov/!deba/publications/OOSB.white.paper.html
Collaboratory tools are currently under development at many sites for experiment control, database management software, videoconferencing, electronic notebooks. The tools need to interoperate, each tool has its own security, communication, and development is on a uniocast structure which will not scale. The motivation is to avoid duplication of effort, integrtae with the PKI, allow concurrent development of applications and infrastructure, provide DOE wide resource location tools, provide reliable & unreliable multicast capabilities, provide synchronous & asynchronous (e.g. for whiteboard) message passing capabilities, and provide high performance.
Added requirements include CORBA compatibility, hierarchical name space, OOP environment, scalable & extensible architecture, Java & WWW support etc.
Looking at providing a modular architecture where each tool plugs into a kind of software infrastructure bus. This seems to translate into using an Object Request Broker bus (CORBA) to provide the glue between the software objects which represent the physical objects.
Greg Chartrand made a proposal to set up an ESCC working group to try and getfunding for active security monitoring. The charter is to provide a forum for actively monitoring at DOE sites to do active monitoring for security intrusions. Products will only be shared among members of the group.
Bill is writing a program plan for ORNL. There is work going on in this area, at various Labs. Bill's idea was to ask around, see who is doing something, get those folks together via a private email list. Bill is worried about setting up a formal group, especially if ask for funding. This could get into a turf war with other people funded for security, it also could get too much visibility for something which is very exploratory at the moment and in a very sensitive area.
Agreed to postpone any formal action to a future meeting at which Greg could advocate his point. In the meantime an email list will be set up. The mail group could then get toegther at the next Esnet, maybe then decide on whether to be more formal, come up with a proposal for funding etc. The email list will be by invitation only. Requests for membership should go to Bill <wingwr@ornl.gov>.
Introduction to SSH. It was devloped at Tatu Ylonen of Helsinki University developed, now available as public domain and commercially. Provides secure communication over insecure networks. Closes IP, routing & DNS spoofing holes. Provides encryption & strong authentication, auto encrypts xwindow sessions. Versions coming available for Mac & PC.
Uses TCP/IP sockets, based on 1024 RSA host key, 768 RSA server key, 64 bit random numbers (cookie) & supported ciphers. Client generates a 256 bit session key using the host & server key of the server and encrypts it using PKCS and RCS.
Supports .rhosts or /etc/hosts.equiv (but not recommended). Support .rhosts or /etc/hosts.equiv + RSA host auth (verifies if .rhosts is OK, encrypts & sends challenge to client using clients publlic key. Client returns MD5 checksum which server validates. Also supports RSA and password authentication. There is Kerberos authentication, but not part of standard distribution, K% additions done at Sandia. User authenticates to Kerberos server, the ticket is passed to the SSH server. SSH supports multiple ciphers including IDEA, DES, triple DES, ArcFour and TSS. The SSH suite consists of an ash client, ssh daemon, ssh file transfer, ssh-key public/private key generation, man pages. SSHD starts at boot time, runs as root. Has lots of options for customization/configuration. The client is more individualizable than the daemon User keys are kept in the home file directory.
May be slow to do file transfers using ssh for slower workstations. SSH is said to be easy to install.
PPPL run AFS server since Mar-94. Do NOT use AFS for user home directories due to lack of transparency for authentication & lack of AFS on some platforms. AFS mainly used by local users who collaborate with off site colleagues. the /usr/local was outgrowing the 2GB SunOS partition limit & using NFS to share /usr/local was unreliable.
Started talking about migrating user home to AFS, since disk management easier. Volume sizes easily moved between disk partitions. Replication provides a more robust environment, caching improves performance over NFS?, common name space simplifies directory organization. Key disadvanges are delayed availability for new releases of the OS. Other considerations are automated tasks (cron) and tokens, @sys sometimes provide too much granularity, sometimes not enough.
/a -> /afs/pppl.gov/@sys, /usr/local -> /a/usr/local etc to make installs easier, i.e. it is built as if in /usr/local.
He is proposing an Esnet-wide /usr/local so it will be kept up to date
by professionals. Reduce security risks which need to be addressed in a
timely manner. With a resonable cache could provide user with a lot of
software with excellent performance. Issues that need to be addressed include
licensed software needds access control, some packages come with configuratiion
files which might need to be distinct from one site to the next. Version
control becomes even more difficult as user community expands and is more
diverse. Might work for an affinity group (e.g. HEP or Plasma).