From: lmccarth@cs.umass.edu
Date: Sun, 25 Feb 1996 21:56:54 +0800
To: cypherpunks@toad.com (Cypherpunks Mailing List)
Subject: Re: InterNIC Guardian Object Draft
In-Reply-To: <199602241712.MAA26212@ops.internic.net>
Message-ID: <199602251334.IAA29519@opine.cs.umass.edu>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

ftp://rs.internic.net/policy/internic/internic-gen-1.txt says:
> Jasdip Singh
> Network Solutions
> Mark Kosters
> Network Solutions
> 
> The InterNIC Guardian Object
> DRAFT

Thanks to Eric Eden for forwarding a copy to cypherpunks. I'd like to 
comment on the proposed set of authentication options (authorization schemes).

[...]
> Auth Scheme
> 
> Authorization scheme used to authenticate a Guardian before updating
> the Object it is guarding. The proposed schemes in an increasing
> order of strength are MAIL-FROM, CRYPT-PW, and PGP [1].
> 
> MAIL-FROM MAIL-FROM will parse the FROM: field in the mail header
> of an update message and match it with the email address
> of the Guardian guarding the Object to be updated.
> MAIL-FROM is the default Auth Scheme.

I realize this is meant to be the simplest/least-secure option. Nevertheless,
it seems to me that checking the "From " header instead of the "From:" header
would increase the security of this option at essentially no computational
cost. (I think "From " is commonly called "From_" in the literature these
days.) From_ is harder to forge than "From:", although that's not saying a
great deal.

Might I assume that the current InterNIC practice is to check "From:" ?
If so, you might consider switching to From_ in the interim, before the
Guardian Object stuff gets implemented.

> CRYPT-PW CRYPT-PW will encrypt the cleartext password supplied
> in an update message and match it with the encrypted
> password of the Guardian guarding the Object to be
> updated. Initially when a new Guardian is being
> registered or the authentication information is being
> added to an existing Contact, the encrypted password
> MUST be supplied. The Unix crypt(3) routine SHOULD be
> used to encrypt a cleartext password.

I think that Unix's md5(1) would be a better transformation choice. It is 
available to a similar extent as crypt(3), and is more inversion-resistant.
I'm not sure how the speeds compare. What sort of volume of update messages 
does InterNIC anticipate handling ?  

Also, if you use a hash function such as MD5, you don't need to fool around
with doing something like E_pass(pass). 

In Section 9.3, it says:
> The authentication information for a Guardian will be visible in WHOIS
> unless the Guardian chooses to keep it private. This information will
> be public by default because a Guarded Object should be protected by
> the inherent strength of the selected authorization scheme rather than
> by hiding the authorization information for its Guardian. 

I certainly appreciate the sentiment expressed here that "security through
obscurity" is a wash. However, in this particular situation I don't think
that's the right issue. Keeping the details of a security algorithm or
protocol is rather dubious in many cases. But it's entirely reasonable and
good for a security protocol to specify that some sensitive application data 
handled by the protocol will be hidden. Encryption is, after all, a way to
hide information....

Let me wax concrete now. :} If a Guardian uses CRYPT-PW and the authentication
information appears in the public WHOIS database, then an attacker can learn
crypt(3)_KEY(pass) just by looking up the WHOIS entry. Assuming the Guardian 
isn't hassling with managing a distinct key to encrypt the password, then the
attacker knows crypt(3)_pass(pass). Now she is all set to do an offline
password guessing attack. So exposing the ciphertext of the encrypted password
introduces a weakness.

More importantly, the CRYPT-PW protocol is subject to a replay attack. A 
passive attacker just needs to eavesdrop on an update message to learn the 
plaintext password. Then she can forge additional update messages using the 
purloined password, causing annoyance to Guardians using AFTER-UPDATE
notification and disruption to those using NOT-CARE update notification 
(i.e. none). 

> PGP PGP stands for Pretty Good Privacy [2]. The sender will
> sign the update message with a Guardian's secret PGP
> key. The InterNIC will verify the received update
> message with the Guardian's public PGP key. 

As far as I can see from the draft, the contact update templates do not
include date or time information. This makes the protocol vulnerable to 
a simple replay attack. An attacker can record update messages and replay
them to InterNIC later. 

Depending upon a Guardian's notification status, this could allow the 
attacker to confuse things by restoring an old contact information record. 
Even if a Guardian is using BEFORE-UPDATE, she might not notice that a
subtle change has been undone. An update notification message arriving on 
the heels of a similar one might get approved by a Guardian, who chalks it
up to a mail transport glitch.

Requiring some sort of timestamp field in the signed portion of the contact
templates would be good.

> How to
> register a Guardian's public PGP key with the InterNIC
> will be explained in another document.

Any hints on what this will be like ?

Hope this helps. Feel free to ask questions.

(cc:ed to cypherpunks@toad.com, jasdips@internic.net and markk@netsol.com)

Lewis	"You're always disappointed, nothing seems to keep you high -- drive 
	your bargains, push your papers, win your medals, fuck your strangers;
	don't it leave you on the empty side ?"  (Joni Mitchell, 1972)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMTBlC2f7YYibNzjpAQEJrgQAvhQHFbLPpL+n3jjFwO0LW4F72d3/lUcJ
yXhlxS0ko7+0SvXfmndAJ41S/queMjhcLwjJZRWtbQbtdc45lXQxJkykXafQz6Je
y+7T7ZwTMAIDAbd8hcpncv1C5NJrCTqEZNHnFxevmSyWtIgxzM+ndugwWyfVULCQ
JfkAa2ssxIA=
=2Q31
-----END PGP SIGNATURE-----