[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CmnLn Elec Exch: 3/30 and 4/02 Minutes
CommonLine Electronic Exchange subcommittee minutes for 03/30/98 and 04/02/98.
-
Russ Judd Great Lakes rjudd@glhec.org
Scott Fullerton* Great Lakes(Chair) sfullerton@glhec.org
Karl Ebert SLMA 105502.3154@CompuServe.Com
John Falconer SLMA
Frank Hum SLMA franklin.r.hum.jr@slma.com
Libby Meeker SLMA Libby.Meeker@SLMA.com
Gary Thomas SLMA 70664.401@compuserve.com
Mike Nolan* PHEAA mnolan@pheaa.org
Darwin Peiffer* PHEAA dpeiffer@pheaa.org
Terry Zuch PHEAA tzuch@pheaa.org
John Hall PHEAA
Linda Laub PHEAA llaub@pheaa.org
Jeff Knass USA Group jknass@usagroup.com
Brian Allison* USA Group BALLISON@usagroup.com
Ron Clark USA Group rclark@usagroup.com
Paul Logston* USA Group plogston@usagroup.com
Mike Brannon USA Group MBrannon@usagroup.com
Matt Parrett USA Group mparrett@usagroup.com
Paul Jansen* USA Group pjansen@usagroup.com
Ki Ha NELA kiha@nela.net
Gary Burleson TGSLC gary.burleson@tgslc.org
Kelly Klipple TGSLC kelly.klipple@tgslc.org
Will Thien TGSLC will.thien@tgslc.org
Warren Sherard Edfund wsherard@edfund.org
Patrick Walters SLFC waltersp@slf.org
Gad Hazum Access ghazum@accessgrp.org
Ed McGowan ESF emcgowan@esfweb.com
Ruth Smith* NYHESC rsmith@hesc.com
Kevin Malmberg NYHESC kmalmberg@hesc.com
Mike Schoeppler NYHESC mschoeppler@hesc.com
Betty Hansman* ISAC bhansman@isc016r1.state.il.us
Mike Yip ISAC
Debbie Phillips* ISAC dphillip@isc016r1.state.il.us
Fred Highsmith* Guarantec fhighsmith@guarantec.com
Tim Hearley* KHEAA thearley@kheaa.com
Mark Lifland Nellie Mae mark_lifland@nelliemae.com
Goeff Boisvert Nellie Mae geoff_boisvert@nelliemae.com
Doug McCaleb* Nellie Mae doug_mccaleb@nelliemae.org
Tom Jurado AFSA twjurado@aol.com
Bill Horn College Foundation whorn@cfi-nc.org
Dawn Harris* College Foundation dharris@cfi-nc.org
Also attending: Jon Kroehler
* = present
=================
*SUMMARY*
Topics discussed: On Monday, the group began to consider options available to
us without access to PGP using the RSA algorithm. We reviewed the
possibilities available to us in the context defined by both the upcoming loan
processing cycle and our longer-term objectives. In Monday's meeting, the
group conducted a brainstorming session structured around the list of known
alternatives generated by Paul Logston ("Choose your Poison" 3/27). On
Thursday, the group discussed whether and how to phase our efforts given this
setback:
- what if anything to do about the summer along with the risk of doing
nothing.
- the time-frame for a longer-term solution
==================
1) *NAI UPDATE*
PGP using RSA is no longer an option for us. To summarize the week's activity:
On Friday March 27, Scott sent a letter via e-mail to Rich Hornstein (NAI VP of
Legal) and Jeff Platon (NAI VP of Business Development) indicating our
displeasure with the information thus far received: that they were withdrawing
the offer to sell the 4.0 Toolkit (This letter was also copied to the
Electronic Exchange Listserve). Scott and Karen Haney also sent the letter to
these people via fax and postal mail.
Scott was called by both Mr. Platon late Monday and received an e-mail from Mr.
Hornstein on Tuesday, and both declared they could no longer sell the toolkit,
because they cannot continue to support RSA in the wake of litigation with RSA
Data Security Inc (RSA DSI).
Scott talked with Brian Spector of RSA DSI on Wednesday to explore the
possibility of licensing the RSA part of PGP directly from them. Mr. Spector
categorically refused saying that 1) there was such hostility toward PGP/NAI
they would have no interest in doing them any favors and 2) it would create a
compromising precedent.
4/3: Adding an interesting twist, Mr. Spector called back Thursday after the
meeting saying that he talked about our situation with his management, and as a
result they have resolved to make it their highest priority to help us out.
2) *BRAINSTORMING OPTIONS: Monday 3/30 meeting*
In Monday's meeting the group went through the list of options presented in
Paul Logston's "Choose your Poison" message and added options g) through i).
The list (borrowing Paul's excellent classification terms and explanations) is
as follows:
a) Use PGP's 32-bit Products: i.e. use Diffie-Hellman algorithm
It seems possible to call a 32-bit ActiveXserver from a 16-bit program. So, we
could write encryption servers in 32-bit development environments that called
PGP's 32-bit SDK, but still provided services to 16-bit programs. This is
actually a pretty attractive option, since it gets us into the supported realm
at PGP, gets us to the algorithm that PGP obviously prefers, and moves us a
little bit closer to going 32-bit. However, the downside is that it is a
substantial development project to actually make a usable server and it does
require a 32-bit operating system (Windows 95, 98 or NT) at the client's site.
Discussion:
This was met with favorable response by the group as an option to consider
further. It seemed unlikely, however, anyone would be able to have this ready
before peak season processing begins.
b) Use the Freeware PGP
The freeware DOS PGP is available just about everywhere. However, calling a DOS
program to do our encryption is aesthetically unpleasing and difficult to
control programmatically. It is also probable that we would be violating the
freeware PGP license agreement by using it for commercial purposes.
Discussion:
Many expressed skepticism about the legality of this. Members agreed to
research this further.
c) Run Naked Through the Internet
In short, don't encrypt. This has the advantage of separating us from all of
the encryption vendors. However, we do run into privacy concerns, since schools
are required to protect this data to some extent and we can't guarantee the
safety of the data as it moves from server to server.
Discussion:
There was widespread skepticism about this. Linda Laub of PHEAA would review
legal standards governing protection of data, although she noted that there are
many state regulations which may differ from, and perhaps be more stringent
than, the national standard.
d) Run Naked Through CompuServe
Another alternative is to use POP3 mailboxes without encryption, but specify
that we only use CompuServe as an ISP. This might be a little more safe than
using the Internet, especially if we can get information from CompuServe about
the routing of their e-mail data, but still ties us to CompuServe. At least
POP3 seems to be the strategic mail platform for them. We would need to find
out who owns these POP3 mailboxes:CompuServe/Worldcom or AOL. This solution
might be the best yet, since it would preserve much of the group's work and
most of our current clients are on the CompuServe network already.
Discussion:
3/30 The group greeted this with some acceptance as a possible fallback
should support for oldmail go away.
4/2 The group felt this would likely not be a trivial effort to implement
and so should not be sought as a direction to take except as becomes necessary
should support for oldmail be withdrawn. Each member will review the impact to
his/her respective agency in implementing such an option. USA Group will
attempt to get reliable estimates from Teemu Kolehmainen of AOL messaging
services as to the future availability of oldmail.
e) Use Symmetric Encryption
There are several symmetric encryption algorithms that we could use outside of
PGP. This would provide some protection for the data. There are a couple of
permutations of this idea. A downside to both of symmetric key options is that
symmetric key encryption doesn't support digital signatures, but this isn't a
very big problem.
- Symmetric-A: Establish one key for the entire network and simply use this to
invisibly encrypt the data. The bad part of that idea comes if the key is ever
compromised --it would be nearly impossible to update the key through all of
the network.
Discussion:
We ruled out this option given the impact to the entire business network
whenever the key is compromised.
- Symmetric-B: each participant creates its own key, which would be stored in
a database of keys at each participants site. There would still be a key
exchange between participants, and if one key became compromised, then only
that participant's key would have to be changed and resubmitted.
Discussion:
This option was considered very unattractive, as it would involve all the
complexity and more of key management found in public key systems without the
benefits.
f) Move the CommonLine Network to an FTP Solution
This is an attractive option, since the protection issues for FTP aren't as big
and most people can do FTP in some fashion. For encryption, we can use SSL
(Secure Sockets Layer) when we connect to the service provider's FTP server.
However, getting everyone's FTP site setup in a compatible manner would be a
nearly impossible task. Also, this idea pretty much nukes all of the work that
we've done so far, since the mail-related issues are much different than those
for FTP.
Discussion:
Secure Sockets Layer is not a given service in ftp. Such a connection would
have to be provided at the ftp server side as well as at the remote users'
side. This being the case, it doesn't seem to offer any clear advantages over
POP3 messaging, and perhaps imposes some disadvantages as a general solution,
particularly in the area of configuration.
g) Everyone use the same proprietary messaging with built-in security
This came up in the 3/30 discussion. The specific form of the idea was the
possibility of everyone using Lotus Notes with its built-in security features.
Discussion:
There is no single proprietary messaging system that we could ask all
CommonLine clients to use. To do so would pose an unreasonable constraint on
processing and would present no apparent short-term or long-term advantages.
h) Look to other encryption vendors
The group considered the possibility of using other encryption systems.
Particularly interesting was the product set offered by Information Security
Systems, a partner or subsidiary of AT&T (cf. Tim Hearley's message "Encryption
Software" 4/1/98). Another possibility is RSA DSI. We have considered them in
the past, but as mentioned above, they have expressed a strong interest in
making RSA DSI attractive.
Discussion:
Tim has contacted Information Security Systems for details and has reported his
findings to date on the CLEE ListServe. We will discuss this at the 4/09
meeting.
4/3: Brian Allison will follow up with RSA DSI, and will report on that.
i) Use packaged functionality developed for our specific needs.
This was discussed in the context of option a) but is applicable to other
options as well. A contractor or a member of the CommonLine group develops the
encryption functions packaged in a such a way as to make integration into SBS
or Host-side processing very easy.
Discussion:
This may have possibilities but there are some issues to resolve before this
solution would be workable.
- If it were to be a contractor, who would contract the services? NCHELP?
- How would that entity be reimbursed for its cost?
- If it were the contribution of a member organization how would users of the
package get support?
A possible answer to this, might be that every user must support itself.
- How would the contributor be reimbursed?
===================
4/02 Discussion
At the 4/02 meeting the group partitioned the problem into short-term issues
(i.e. what if anything should be done prior to the processing cycle this
summer) and long-term issues (i.e., what should be done for the period after
that.)
3) *Review of developments leading to the retraction of PGP using RSA*
The group reviewed its processes leading to last week's developments.
a) It is clear that NAI is still has problems with poor internal communication
and poor marketing relations. It is also true that had we specified the use of
their current technology, we would probably not have had any of the
difficulties we have experienced with them. We should consider this in future
specifications -- there is a risk in planning to use obsolete technology.
b) There are inherent difficulties negotiating a common agreement with a vendor
for independent agencies. We will probably always encounter some difficulties
negotiating with vendors because of the complex arrangements we collectively
require combined with the relatively low commitment we individually are willing
to make. The letter of intent was a very good idea, one we should use earlier
in the negotiation process, which should help alleviate the problem
4) *Short-Term concerns and the availability of OldMail*
The prospect of "running naked over CompuServe", using the Worldcom network
and POP3, has a great enough impact that many felt it would be unlikely anyone
would develop for this option unless the loss of oldmail services seemed
imminent. Members would attempt to assess the actual development costs for this
solution. In the meantime, Brian Allison will try to get an accurate
indication from Teemu Kolehmainen of CompuServe/AOL as to:
a) how long we can expect oldmail to remain available;
b) how many other customers are still using it;
c) how much lead-time we can expect before they withdraw it;
5) * Long-term Objectives*
The group considered, given the delay that we now face, whether we would want
to reconsider the use of POP3 messaging as our long-term solution or whether we
would want instead to look at other models. The consensus of the group was to
stay with POP3. This being the case, we will need to identify another
encryption standard and product set. The currently known alternatives consists
of:
a) the offerings of Information Security Corporation;
b) PGP using Diffie-Hellman;
c) the offerings of RSA DSI;
This will be addressed in the 4/09 meeting.
==================
*ELECTRONIC EXCHANGE LISTSERVE*
These minutes will go out via the Electronic Exchange listserve. They can be
viewed with a browser at the archive site http://lists.glhec.org/cl-elec-exch
(case sensitive). To subscribe to the listserve, send a message to
cl-elec-exch-request@lists.glhec.org. Put the word subscribe in the body of
the message (You may make the subject anything you want). To post to the
listserve send messages to cl-elec-exch@lists.glhec.org (You must first have
subscribed).
--------------------------------
NEXT SCHEDULED MEETING:
Monday 4/09/98 10a.m. central time. The number to call is (800) 374-8567. When
asked for the name of the conference, reply "CommonLine Electronic Exchange."
If asked for the host's name, reply "Scott Fullerton"
------------
Agenda
1) CompuServe/AOL update
2) Product Enquiry update;
a) Information Security
b) RSA DSI
3) Short-term Strategy
4) Long-term Strategy
2 Testing (revised addendum draft submitted for review);
3 Algorithm Identifier (revised addendum draft submitted for review);
4 Key verification (proposal to be submitted by Doug McCaleb);
5 PGP/MIME vs MIME Discussion of proposal by Paul Logston (see ListServe
Archive "An Encryption Proposal" (2/9/98);
}
else
Consider our options;
------------------------------------------------------