Re: Towards Rough Concensus and Running Code

[Alex Alten <[e-mail]>]

>      We have reviewed the various proposals which were submitted for
>      consideration to the working group.
> 
...
> 
>      We invite your comments!
> 
> Keith, Marshall, and Glenn
...
> 
> 
> 
>                    #######
> 
> Proposal:     Security Encapsulation of SNMP
> Author:       Alten
> Draft:        [1] draft-alten-snmp-sec-encap-00.txt
> 
> First, we observe that in the history of the Internet there has been
> very limited success in deploying a public-key infrastructure.  Key
> management is, of course, the problematic aspect of any technology based
> on public key cryptography.
> 

This observation is incorrect.  Public-key based authentication is 
becoming very successful on the Internet, the prime example is PGP which
uses RSA (or PKC if you prefer) technology.  I can cite numerous other
protocols which are now relying on public-key technology for strong,
long-term authentication.  Key management is a problem for both
public-key and classic encryption technology (like DES).  In fact, 
key management over an open, unsecure network is more difficult for 
classic than for public-key technologies.  The perceived "problematic
aspect" is simply because the immediate difficulties of dispersing classic
keys is so great that over-the-horizon problems are not even dealt with,
while modern public-key methods have moved on and are now on the horizon
grappling with these new problems (such as certifying unknown keys).

> Further, in the US, PKC is a patented technology.  We observe that, in
> the history of the IETF, that standardization of technology involving
> claims of intellectual property has proven problematic (No part of the SNMP
> standard is encumbered with intellectual property considerations.)
> 
> Therefore, we claim the following: it unwise to base any aspect of SNMP
> on PKC.

Almost all modern encryption algorithms which have gone through long and 
rigorous cryptanalysis are protected by patents.  That is the nature of 
the beast and if we wish to move forward we will have to reconcile with 
it.  Two worlds are colliding, networking and encryption, and they both 
have very different histories and mores.  

Now to deal with your specific compliant about RSA (PKC) being patented.
I looked up the expiration dates of some public key patents.

   ElGamal is unpatented.
   Diffie-Hellman expires 4/29/1997.
   Merkle-Hellman expires 8/19/1997.
   RSA            expires 9/20/2000.
   
In my proposal I specify RSA (PKC) and ElGamal public-key algorithms as
the mechanisms for providing authentication.  If you are really concerned
about licensing problems then use ElGamal.  The US Government is using it
in their Digital Signature Standard.  This completely resolves your 
complaint.

> 
> As such, we feel that the working group should reject this proposal.
> 

It's a pity that you are recommending rejection.  It's obvious that the
members of the committee did not examine my proposal carefully.

>                    #######
...
> 
> Proposal:     SNMPv2+USEC
> Auathors:     Galvin, McCloghrie, Rose, Waters
> Drafts:       draft-kzm-snmpv2-intro-alt-00.txt
>          draft-kzm-snmpv2-smi-alt-00.txt
>          draft-snmpv2-tc-ds-03.txt (not changed)
>          draft-kzm-snmpv2-tm-ds-03.txt
>          draft-kzm-snmpv2-conf-alt-00.txt
>          [10] draft-kzm-snmpv2-adminv2-alt-00.txt
>          [11] draft-kzm-snmpv2-sec-alt-00.txt
>          draft-kz+m-snmpv2-proto-alt-00.txt
>          draft-kzm-snmpv2-mib-alt-00.txt
>          draft-kzm-snmpv2-coex-alt-00.txt
> 

I would like to observe that User-based Security Model for SNMPv2 [10]
(USEC) is simply the old wolf in new sheep's clothing.  The wolf of 
course is the classic encryption standard DES which been proposed 
unsuccessfully as the foundation of SNMP security for the past four
years.  DES has several problems.  First, key management is difficult
and does not scale well.  To do key management well requires a key
server, e.g. Kerberos, which defeats the purpose of keeping SNMP
"simple".  Second, DES cannot be exported from the USA if it encrypts
useful data.  Third, DES is getting old.  Even the NIST was reluctant
to recertify it for this current 5 year period.  The new sheep's
clothing is MD5 with a shared secret included in the hash.  First,
the shared secret has the same problem with distribution as DES does
in distributing its keys.  Second, current cryptanalysis research of
MD5 has thrown some doubt on its strength.

Therefore I claim the following:  It is unwise to base any aspect of
SNMP security only on MD5 and DES.

As such, I feel that the working group should reject this USEC part of
the proposal.

> 
>                    #######
> 
> 
> 

-- 

Alexander I. Alten
[e-mail]
[phone]

Novell, Inc.
Advanced Access Applications Division
Member of Technical Staff
Mail Stop F1-42-D2
2180 Fortune Drive
San Jose, CA  95131  
USA