Subject: [dtn-interest] FW: Internet Magazine Out of this world; Internet Futures; Vint Cerf foresees Internet on Mars
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Date: Mon, 24 Feb 2003 13:37:11 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

>Internet Magazine
>
>March 22, 2003
>
>SECTION: Pg. 42; ISSN: 1355-6428
>
>IAC-ACC-NO: 97891910
>
>LENGTH: 1734 words
>
>HEADLINE: Out of this world; Internet Futures; Vint Cerf foresees Internet
>on Mars
>
>BYLINE: Dunn, John
>
>BODY:
>One of the Internet's forefathers is making plans for a brand new
>internet--on the planet Mars. John Dunn explains how this extra-terrestrial
>initiative could take the Net to the final frontier
>
>Vint Cerf has been described as 'far-reaching' in his time, but when he said
>he wanted to take the Internet into outer space, there were plenty of people
>who thought he was taking the phrase a little too literally. His
>extraordinary plan proposes the creation of a two planet domain structure by
>2009-- .Earth and Mars--extending to other planets as they are subsequently
>visited by manned or unmanned spacecraft. "Lest you think this is all
>fantasy, let me assure you that it is quite real," he is reported to have
>told an astonished audience as long ago as the 1998 annual meeting of the
>Internet Society.
>
>Cerf is best known by his endlessly repeated honourary title 'father of the
>Internet'. This is a credit given to him -- as any good student of Internet
>history knows -- for his role in co-authoring the family of protocols on
>which the Net is based, known today as TCP/IP or simply P. In fact the
>Internet has a number of 'fathers' who helped turn it from a backwater
>project at the US Defense Advanced Research Project Agency (DARPA) into the
>Internet we know and use today, but Cerf has certainly earned the right to
>be regarded as one of its most influential figures.
>
>Less than five years after he announced his proposal, this extra-terrestrial
>expansion to the Internet now has a name--the 'InterPlaNet', or IPN for
>short. It's set to make its first experimental journey into space with the
>launch of the NASA Jet Propulsion Laboratory 0 PL) Deep Impact mission to
>visit the comet Tempel 1 in 2004. When it reaches the comet on July 4th
>2005, the two-part Deep Impact spacecraft will begin transmissions using
>established space communications protocols, but will also send some signals
>using an entirely new InterPlaNet protocol (CFDP, or Coherent File
>Distribution Protocol), which is capable of transferring data as whole
>files.
>
>This will be the first of a new type of space communications protocols,
>dubbed IPN bundles, which can trace their conceptual ancestry by one route
>or another back to the formation of the Earth-bound Internet with TCP and
>IP. It won't be very spectacular and it's not exactly the sort of event
>people will rush home to watch on TV, but with the Deep Impact mission and
>CFDP file transfer, the InterPlaNet will have been, if not 'turned on', then
>at least brought quietly into low-level existence.
>
>More excitingly, NASA has scheduled a number of missions to Mars from 2005.
>These are expected to be equipped with software to allow them to operate, in
>principle at least, as the first nodes in a new, static .Mars domain
>permanently connected to Earth. It is tempting to see the Mars domain as
>simply an extension to the Earth's Internet, but it's more accurate to think
>of it as an entirely new Internet in its own right, albeit one that consists
>of only a tiny number of nodes.
>
>If the Earth-based Internet can be described as a 'network of networks' then
>by contrast, the InterPlaNet will be the galactic 'network of Internets' of
>which the .Earth Internet will be only one sub-Internet. Eventually, every
>planet in the solar system could have its own InterPlaNet domain (or
>'region' in InterPlaNet speak), with moons and possibly other objects such
>as large asteroids forming sub-domains.
>
>As with the Internet before it, the first users of the InterPlaNet will be
>scientists, who will use it to talk to their billion-dollar spacecraft and
>assorted Earth-orbiting satellites more rapidly, cheaply and efficiently
>than before. A decade or two into the future, if humans start venturing into
>space again -- possibly to visit Mars or revisit the Moon--the need fore
>very day communications will increase. Don't expect to be able to remotely
>control a Mars webcam any time soon, but if you're related to one of the
>first Mars explorers sending the the odd email to [email-masked]
>(with the '.sol' standing for the Sun) is not beyond the realms of
>possibility in your lifetime.
>
>Galaxy-wide wait
>
>If the InterPlaNet is based on ideas harvested by Cerf and JPL from the
>workings of the Internet, then in almost every other respect it will operate
>as a very different type of network. Building an Internet-style
>communications network in space is no easy task. Apart from the obvious
>problems of limited bandwidth and time delay (radio signals travelling at
>the speed of light from our nearest neighbour Mars take many minutes -- and
>sometimes hours -- to cross the 48 million miles to Earth), engineers also
>have to take into account large bodies, such as planets and moons, getting
>in the way of transmissions.
>
>If the transmission point is on the surface of a planet or moon, then it
>might not always be able to work due to weather conditions -- storms of
>electromagnetic particles from the Sun can interfere with radio
>communication. A planet can also simply rotate away from the Earth or an
>orbiting planetary relay station, blocking transmissions.
>
>The InterPlaNet has also had to overcome some tricky design issues. The
>Earth's Internet works on the principle that data can be sent, acknowledged
>as having being received, and, if not accurately received, resent. Operating
>across possibly hundreds of millions miles of deep space, this design would
>be silly. In a worst-case scenario, it could be days before a packet
>acknowledgement was received, stalling communications and stretching the
>movement of even small amounts of data to days or weeks.
>
>Passing the baton
>
>So the InterPlaNet pioneers have come up with some new ideas, some of which
>Cerf and his colleagues at JPL concede still have to be worked out in
>detail. The InterPlaNet's backbone link will need to be highly tolerant of
>delays, and any spacecraft using it will not be able to make assumptions of
>how quickly a recipient can respond to a transmission. So data will have to
>be 'bundled' into complete units for transmission between interplanetary
>relay stations, removing the need for the acknowledgement and
>error-correcting 'chatter' which the terrestrial Internet uses where data is
>split into packets.
>
>Each node or spacecraft in the InterPlaNet would take control of a data
>bundle in a 'custodial' store-and forward fashion, passing it on only when
>the next node is guaranteed to be able to receive it correctly. In the early
>days, the links between nodes will use radio waves, but there has been talk
>of using laser light in future to cut down on background interference.
>
>Once data reaches, say, a lander on the surface of Mars, it would be
>converted back to conventional TCP/IP Internet protocols within the .Mars
>Internet domain or region. The different devices on the planet's surface
>would then be able to send data to each other by using a wireless network.
>
>In the long term, the InterPlaNet has the potential to completely change the
>way we think of and understand our portion of the galaxy. At the moment, we
>have a limited vocabulary to talk about what surrounds us in space. Planets,
>moons, the odd comet and asteroid are all named and located according to
>schemes that have hardly moved on from the 16th Century days of the
>astronomer Nicholas Copernicus. The Solar System has no structure to explain
>what it is in logical terms, other than the position of a body in relation
>to the Sun or the Earth.
>
>In the future, the Solar System could be made up of logical domains, like
>the Internet country and commercial domains used on Earth. There's nothing
>to stop this scheme being extended beyond the Solar System into the wider
>galaxy, assuming we're clever enough to figure out ways of travelling
>further.
>
>Time will tell
>
>The long mission timescales and vast distances involved mean that the
>InterPlaNet is a story that will probably take a century to unfold. But
>future generations could look back on its arrival as a more important event
>than even the Internet itself-the moment when the idea of reliable and
>permanent interplanetary communication was first thought through.
>
>Just as the Internet appears to have shrunk the distances between countries,
>cultures and economies, so the InterPlaNet could yet do the same for the
>unexplored and mysterious emptiness of space. If one day humans ever head
>out into the dark blue celestial yonder in earnest, they'll have Vinton
>Cerf, 'father of the solar InterPlaNet', and the team at NASA'sJPL to thank
>for making an important part of it possible.
>
>Useful Links.
>
>The best place to start for more information about the InterPlaNet (IPN) is
>at the website set up to coordinate its development: www.ipnsig.org
>
>Vinton Cerf has a detailed explanation of the InterPlaNet at:
>www.ipnsig.org/reports/memo-ipnrg-arch-oo.pdf
>
>Details of NASA's Jet Propulsion Lab space missions can be found at:
>www.jpl.nasa.gov
>
>RELATED ARTICLE: InterPlaNet Primer
>
>What is the InterPlaNet?
>
>A proposal to create an interplanetary communications 'backbone' using
>satellites orbiting Earth and spacecraft positioned between, and orbiting
>around, planets. Craft on or around the surface of planets would use new
>Internets created for each planet. As on Earth, these would use TCP/IP.
>
>Who's behind it?
>
>It's a joint ventu(e between a small team at NASA's famous Jet Propulsion
>Labs OPL , headed by veteran spate engineer Adrian Hooke, and Internet
>pioneer Vinton Cerf. It's funded through the US Defense Advanced Research
>Projects Agency (DARPA) Next-Generation Internet Initiative, and by NASA
>itself.
>
>Why now?
>
>Space-bound communications are becoming increasingly standardised, with
>different agencies seeking to control spacecraft and satellites to use the
>same communications protocols and ground networks. This is primarily to keep
>costs down. Spacecraft are also carrying more standardised computing
>systems. The InterPlaNet backbone will help tie all this hardware together
>into one logical network.
>
>What's the timeline?
>
>The first mission, to experiment with basic principles, will be part of
>NASA's Deep Impact mission in 2004/ 5. Future Mars missions will create the
>Mars InterPlaNet region around the red planet -- this will form the
>universe's second Internet (as far as we know). The InterPlaNet will be
>extended to every other planet, as each is visited.
>
>IAC-CREATE-DATE: February 21, 2003

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

Date: Sat, 01 Feb 2003 13:38:22 -0500
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Re: elliptic curve methods
Sender: [email-masked]

--Boundary_(ID_kNpLygRTw8528X/RbPBi+g)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: QUOTED-PRINTABLE

>Date: Fri, 31 Jan 2003 10:30:05 -0500
>From: Robert Moskowitz <[email-masked]>
>Subject: Re: elliptic curve methods
>X-Sender: rgm-sec@localhost
>To: "vinton g. cerf" <[email-masked]>
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>X-Rcpt-To: <[email-masked]>
>
>Good to hear from you Vint.
>
>At 06:46 AM 1/30/2003 -0500, vinton g. cerf wrote:
>
>>Thanks for sending out the references on key management.
>>These proved to be very timely for some work I am doing
>>at JPL. We reviewed our basic security requirements
>>yesterday and were confronted with the interesting
>>problem that symmetric key management in extremely
>>high delay environments (e.g. interplanetary Internet)
>>made it desirable to achieve key sharing by methods
>>not requiring a lot of round trips between the
>>parties. This seemed to rule out Diffie-Hellman
>>key construction.
>>
>>Would you have time to review a draft of about 5-6
>>pages describing our current thinking?
>
>Yes.  And I will send you my SSPP drafts.  D-H can be OK if used jud=
iciously.
>
>SSPP came out of my work on the RADIUS client secret needed in every=
 IEEE 802.1x authenticator (i.e. wireless APs!).  I have 2 drafts in =
works applying SSPP over SNMP.
>
>I am also working on SSPP over HTPP, but that may be a bit chattier =
than over SNMP....
>
>
>
>
>
>Robert Moskowitz
>TruSecure Corporation
>Security Interest EMail: [email-masked]

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

--Boundary_(ID_kNpLygRTw8528X/RbPBi+g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

   Internet Draft                                          R. Moskowi=
tz
   Document: draft-moskowitz-shared-secret-                    ICSAla=
bs
   provprotocol-01.txt
   Expires: June 2003                                      January 20=
03

                    Shared Secret Provisioning Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documen=
ts
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress=
."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   Shared secrets are common in IETF protocols.  Setting these shared
   secrets is typically defined as out of scope of those protocols.
   The upshot of this approach is poor security practices in setting
   these secrets and, through the life of the implementation, changin=
g
   these secrets.  The Shared Secret Provisioning Protocol (SSPP)
   provides a mechanism for both setting and changing shared secrets
   that are provably strong.

Conventions used in this document

   In examples, "C:" and "S:" indicate activities by the client and
   server respectively.

Moskowitz                Expires - June 2003                 [Page 1]
=0C
                 Shared Secret Provisioning Protocol    December 2002

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"=
,
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

Table of Contents

   1. Introduction...................................................=
2
      1.1 Diffie-Hellman and Man-in-the-Middle Attacks...............=
2
   2. The Diffie-Hellman Key Agreement Schemes.......................=
3
      2.1 The Fixed Field Diffie-Hellman exchange....................=
3
      2.2 The Elliptic Curve Diffie-Hellman exchange.................=
3
      2.3 The Key Derivation Function................................=
4
   3. The Shared Secret Provisioning Protocol........................=
5
      3.1 Managing Risk in SSPP......................................=
6
   Security Considerations...........................................=
6
   References........................................................=
7
   Acknowledgments...................................................=
7
   Author's Addresses................................................=
7

1. Introduction

   Provisioning strong, shared secrets is frequently considered as
   'out-of-scope' in most protocols that use them.  Yet, the quality =
of
   shared secrets has a significant impact on the security
   characteristics of these protocols.  Many of the attacks are
   specifically related to the prevalent use of weak shared secrets.
   This calls out for a standard protocol to provisioning strong shar=
ed
   secrets that can be implemented over case-specific transports.

   The Shared Secret Provisioning Protocol (SSPP) provides a mechanis=
m
   for both setting and changing shared secrets that are provably
   strong.  It is based on the well-known properties of a Diffie-
   Hellman Key Agreement.  Both Fixed Field and Elliptic Curve forms
   are available.  The key derivation methodology is derived from the
   NIST Key Management Schemes proposal [3] which drew heavily on X9.=
42
   and x9.63.

   This is a basic exchange; the actual implementation is left to
   specific cases.  Although SSPP is based on static Diffie-Hellman
   keys, the use of nonces permit it to be rerun whenever a new share=
d
   secret is needed without changing a Diffie-Hellman key.

1.1 Diffie-Hellman and Man-in-the-Middle Attacks

   Although Diffie-Hellman is commonly used for establishing a secret
   between two parties, typically buried within a complex protocol li=
ke

Moskowitz                Expires - April 2003                 [Page 2=
]
=0C
                 Shared Secret Provisioning Protocol    December 2002

   IKE [4], Diffie-Hellman by itself has a significant man-in-the-mid=
dle
   attack.  The method used to detect this attack is to validate the
   public Diffie-Hellman keys that they really came for the expected
   party.  This attack is symmetric.  That is really only one party
   needs to validate the other=92s public key and back off on the
   exchange if the validation fails.

   This symmetric property is important as it allows SSPP to be used =
in
   headless devices that cannot easily validate the public key of the
   other party.

2. The Diffie-Hellman Key Agreement Schemes

   There are many variants defined for Diffie-Hellman Key Agreement
   Schemes.  They vary first in how many static and ephemeral key pai=
rs
   and if the math is Fixed Field or Elliptic Curve.  Then they vary =
in
   if the derived Diffie-Hellman secret is used directly or if it is =
an
   input to a keyed hash that produces the actual shared secret.

   SSPP uses 2 static and no ephemeral Diffie-Hellman key pairs.  Bot=
h
   Fixed Field and Elliptic Curve methods are allowed.  The key produ=
ce
   from the Diffie-Hellman exchange is inputted into an HMAC-SHA1 [5]
   keyed hash along with identities for each party and a large, rando=
m
   nonce from each party.

2.1 The Fixed Field Diffie-Hellman exchange

   Each party has a static key pair (X, Y) that was previously
   generated using the same domain parameters (p, q, g). Party C has
   (Xc, Yc); party S has (Xs, Ys). Each party must obtain the other
   party=92s static public key.  One must obtain the other's in a tru=
sted
   manner.

   Each party computes the shared secret Zs as shown below, and then
   computes the shared secret by invoking the key derivation function
   using Zs.

                  Party C              Party S

   Input          (p, q, g), Xc, Ys    (p, q, g), Xs, Yc
   Computation    Zs =3D Ys^Xc mod p     Zs =3D Yc^Xs mod p

2.2 The Elliptic Curve Diffie-Hellman exchange

Moskowitz                Expires - April 2003                 [Page 3=
]
=0C
                 Shared Secret Provisioning Protocol    December 2002

   Each party has a static key pair (ds, Qs) that was previously
   generated using the same domain parameters (q, FR, a, b, [SEED], G=
,
   n, h). Party C has (dsC, QsC); party S has (dsS, QsS). Each party
   must obtain the other party=92s static public key.  One must obtai=
n
   the other's in a trusted manner.

   Each party computes the shared secret Zs as shown below, and then
   computes the shared secret by invoking the key derivation function
   using Zs.

                  Party C                 Party S

   Input          (q, FR, a, b, [SEED],   (q, FR, a, b, [SEED],
                  G, n, h), dsC,QsS       G, n, h), dsS,QsC
   Computation    (Xs, Ys) =3D hdsCQsS      (Xs, Ys) =3D hdsSQsC
                  Zs =3D Xs                 Zs =3D Xs

2.3 The Key Derivation Function

   The key derivation function is used to shared secret from Zs as
   follows:

   Function call:

   kdf(Zs, C, S, keydatalen, hashlen, NonceC, NonceS)

   Input description:

   1. A bit string Zs is defined above.

   2. Bit strings C and S that denote the identities of the
      participating parties, where C is the party that initiated the
      key establishment process, and S is the responder in the key
      establishment process.

   3. An integer keydatalen that is the length in bits of the shared
      secret to be generated.  keydatalen must be less than hashlen x
      (2^32-1).

   4. An integer hashlen that is the length in bits of the hash
      function to be used to derive the shared secret.  Thus the
      selection of SHA-1, 256, or 512 is determined by the size of th=
e
      desired shared secret.

   5. Bit strings NonceC and NonceS are nonces from the parties C and=
 S
      respectively.  The recommended size for the nonces is twice
      hashlen.

Moskowitz                Expires - April 2003                 [Page 4=
]
=0C
                 Shared Secret Provisioning Protocol    December 2002

   Process:

   a. Initiate a 32-bit, big-endian bit string counter as x00000001.

   b. For i=3D1 to i=3D int(keydatalen/hashlen), do the following:

     Compute Hashi =3D HMAC-SHAn(Zs,(counter || min(C,S) || max(C,S) =
||
      keydatalen || hashlen || min(NonceC,NonceS) ||
      max(NonceC,NonceS)))
     Increment counter
     Increment i.

   c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, an=
d
     let it denote the (keydatalen - (hashlen x (j-1))) leftmost bits
     of Hashj otherwise.

   d. Set sharedsecret =3D Hash1 || Hash2 ||...|| Hashj-1 || Hhashj.

   Any attempt to call the key derivation function for a shared secre=
t
   of length greater than or equal to hashlen x (2^32-1) bits must
   output "invalid" and stop.

3. The Shared Secret Provisioning Protocol

   In SSPP, the client is the party that starts the exchange and is
   capable of validating the other party=92s public key.  This may we=
ll
   NOT be the client in the normal sense.  For example, if SSPP is us=
ed
   to set a shared secret between a headless monitoring device and a
   data collection server, the server may be the SSPP client, as it m=
ay
   have a UI to check the fingerprint of the headless device's public
   key.

   The basic protocol is:

     C:  REQUEST values from Server
     S:  Generate NonceS
         SEND (Domain parameters, Public key, AddressS, NonceS)
     C:  If Domain parameters do not match Client's, stop
         If the Public key is not valid, stop
         Generate NonceC
         Generate Shared Secret
         SEND (Public key, AddressC, NonceC),
            LTRUN96(HMAC-SHA1(Shared Secret, (Public key || AddressC =
||
            NonceC)))
     S:  Generate Shared Secret
         SEND LTRUNC96(HMAC-SHA1(Shared Secret, (AddressS || NonceS))=
)

Moskowitz                Expires - April 2003                 [Page 5=
]
=0C
                 Shared Secret Provisioning Protocol    December 2002

3.1 Managing Risk in SSPP

   There are many potential opportunities for attacks against SSPP
   unless limits are placed on its usage as a PROVISIONING protocol.
   An SSPP implementation MUST have controls placed on servers as to
   when they are available to limit attacks against them.  A server h=
as
   no control over which clients provision secrets with them.  A
   resource limited headless device could be rendered useless through
   this way.  It is best if SSPP is only available at device setup ti=
me
   or when triggered through a process authenticated with an existing
   established shared secret.

   Since for the server, it is possible to attack the nonce state, th=
e
   server implementation could use the same nonce until an SSPP
   exchange is completed, and only then select a new nonce for the ne=
xt
   SSPP request.

   The client needs some method of validating the server=92s public k=
ey.
   This can be through a check of the fingerprint (hash) of the publi=
c
   key, where the fingerprint was obtained in some out-of-band proces=
s.
   Or the physical network between the client and server might be suc=
h
   that no man-in-the-middle is possible (for example with a crossove=
r
   cable in a deployment staging area).

   Any instantiation of SSPP needs to examine how an attack might occ=
ur
   and mitigate those attacks.

Security Considerations

   This protocol uses an un-authenticated Diffie-Hellman exchange.
   This is open to a Man-in-the-Middle attack.  The recommended
   practice for this is that there MUST be a mechanism for the client
   to validate the server=92s Diffie-Hellman public key, or for a ris=
k-
   appropriate assurance that there is no man in the middle between t=
he
   client and server.

   The former can be addressed by client system presenting in its UI
   the fingerprint of the public key.  The operator would check the
   fingerprint with a copy obtained out-of-band (for example stamped =
on
   the server).  The later can be addressed by connecting the client
   and server with a crossover cable or by trusting the deployed
   cabling (as in a small office).

   The server is potentially open to establishing a shared secret wit=
h
   any system.  Since the SSPP server is typically a client for all
   other services, this could leave it open to attack through the
   services that the shared secret is suppose to protect.  As such,
   there must be an external control on the use of SSPP for the

Moskowitz                Expires - April 2003                 [Page 6=
]
=0C
                 Shared Secret Provisioning Protocol    December 2002

   servers.  For example, a device might only be an SSPP server when =
in
   factory default state or when put into it via some protocol
   authenticated with an existing shared secret.

   The size of the Diffie-Hellman keys and the size of the SHA hash
   determine the strength of the shared secret.  It is up to each
   application of SSPP to select these values, based on the needed
   shared secret strength.

References

                   =20
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BC=
P
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  NIST, "Key Establishment Schemes Workshop Document", November
      2001.
      http://csrc.nist.gov/encryption/kms/schemes_workshop_doc.pdf

   4  Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC
      2409, November 1998.

   5  Krawczyk, H., and Bellare, R., "HMAC: Keyed-Hashing for Message
      Authentication", RFC 2104, February 1997

Acknowledgments

   This document is the result of the first IETF Credential
   provisioning workshop and extracted from the original RADIUS Clien=
t
   Kickstart Internet Draft.

Author's Addresses

   Robert Moskowitz
   TruSecure/ICSAlabs
   1000 Bent Creek Blvd, Suite 200
   Mechanicsburg, PA
   Email: [email-masked]

Moskowitz                Expires - April 2003                 [Page 7=
]
=0C

--Boundary_(ID_kNpLygRTw8528X/RbPBi+g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

   Internet Draft                                          R. Moskowi=
tz
   Document: draft-moskowitz-sspp-snmp-00-p1.txt               ICSAla=
bs
   Expires: July 2003                                      January 20=
03

                              SSPP over SNMP

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documen=
ts
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress=
."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   The Shared Secret Provisioning Protocol (SSPP) [2] provides the bo=
th
   the cryptographic functions and the basic protocol for provisionin=
g
   shared secrets based on a Diffie-Hellman key exchange.  This
   document describes the basic SNMP functions to support SSPP.

Conventions used in this document

   In examples, "C:" and "S:" indicate activities by the SSPP client
   and SSPP server respectively. "P:" indicate activities by the SSPP
   proxy.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"=
,
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [3].

Moskowitz                Expires - July 2003                 [Page 1]
=0C
                            SSPP over SNMP                January 200=
3

Table of Contents

   1. Introduction...................................................=
2
      1.1 Reasoning for using SNMP as an SSPP transport..............=
2
      1.2 Terms and Protocol components..............................=
3
      1.3 Variables used.............................................=
4
      1.4 The MIB objects............................................=
4
   2. The basic SNMP exchange........................................=
5
      2.1 Validating the Diffie-Hellman Public Keys..................=
6
   3. Additional exchanges...........................................=
6
      3.1 Changing a shared secret...................................=
6
      3.2 Proxying SSPP through an established Client................=
7
   4. Application of SSPP over SNMP..................................=
8
      4.1 EXAMPLE: RADIUS Client Secret..............................=
9
   Security Considerations...........................................=
9
   References.......................................................1=
0
   Acknowledgments..................................................1=
0
   Author's Addresses...............................................1=
0

1. Introduction

   The Shared Secret Provisioning Protocol (SSPP) provides the
   cryptographic functions and basic protocol for provisioning strong=
,
   shared secrets.  For SSPP to be deployed, it needs a transport-lay=
er
   protocol.  This document describes the use of SNMP for transportin=
g
   SSPP.

   SSPP is presented in three forms.  The principle form is the basic
   exchange.  An important adjunct form is the modified exchange for
   changing the shared secret where there already is a relationship
   between the client and server.  Finally there is the proxy exchang=
e
   where the server's policy restricts it to only one client using th=
e
   basic exchange, but that client can act as a proxy to other client=
s.

   At this state in its development, SSPP over SNMP is very general.
   It will evolve through reviews and its application in provisioning
   existing shared secrets like the shared secret between a RADIUS
   Client and Server.

1.1 Reasoning for using SNMP as an SSPP transport

   There are many shared secrets that protect machine-to-machine or
   process-to-process datagrams.  SNMP is a common protocol on the
   systems that have these shared secrets, making it an attractive
   transport for SSPP.  SNMP is attractive for transporting SSPP for
   the following additional reasons:

Moskowitz                Expires - July 2003                 [Page 2]
=0C
                            SSPP over SNMP                January 200=
3

     Shared secrets are typically the first item to be configured in =
a
     new deployment and at the 'out of the box' state, SNMP is ready =
to
     use in most systems.

     The SSPP client needs to discover the SSPP server after the late=
r
     is deployed.  SNMP has a well-developed system discovery
     methodology.

     SNMP is a very lightweight protocol to use in small headless
     devices.

1.2 Terms and Protocol components

     SSPP is a Client/Server protocol that can use a specialized prox=
y.
     In this standard, all references to Client, Server are SSPP
     clients and servers unless specifically named (e.g. RADIUS
     Server).  All references to a proxy are for an SSPP proxy.  SNMP
     components are Agents and Managers as follows:

     SSPP         SNMP

     Client       Manager
     Server       Agent
     Proxy        Agent to the SSPP client
                  Manager to the SSPP server

     +-------------+                            +-------------+
     | SSPP Client |                            | SSPP Server |
     |             |           SSPP             |             |
     |             |<-------------------------->|             |
     | SNMP Manager|           SNMP             | SNMP Agent  |
     |             |                            |             |
     +-------------+                            +-------------+

                     Figure 1. Basic system flow

     +-------------+          +-------------+          +-------------=
+
     | SSPP Client |          | SSPP Proxy  |          | SSPP Server =
|
     |             |   SSPP   |             |   SSPP   |             =
|
     |             |<-------->|             |<-------->|             =
|
     | SNMP Manager|   SNMP   | SNMP Agent/ |   SNMP   | SNMP Agent  =
|
     |             |<-+       |      Manager|       +->|             =
|
     +-------------+  |       +-------------+       |  +-------------=
+
                      |            SSPP             |
                      +-----------------------------+
                                   SNMP

Moskowitz                Expires - July 2003                 [Page 3]
=0C
                            SSPP over SNMP                January 200=
3

                        Figure 2. Proxied system flow

1.3 Variables used

   AddressC The address of the Client, as chosen by the Client
   AddressP The address of the Proxy, as chosen by the Proxy
   AddressS The address of the Server, as chosen by the Server
   DHC      The Client's Diffie-Hellman public key
   DHS      The Server's Diffie-Hellman public key
   NonceC   Nonce from the Client
   NonceS   Nonce from the Server
   Parms    Diffie-Hellman Domain Parameters
   SigC     The HMAC signature generated by the Client
   SigP     The HMAC signature generated by the Proxy
   SigS     The HMAC signature generated by the Server

1.4 The MIB objects

   The Server has some specific MIB objects and two tables of objects
   for each Client.  The Proxy also has a table of objects.  The Serv=
er
   specific objects are:

   Domain Parameters
   Diffie-Hellman key pair (the private key MUST be protected from
   reading)
   Server Address
   Nonce

   The Server's Client table objects are:

   Client Address
   Client Diffie-Hellman public key
   Client Nonce
   Client Signature
   Server Signature
   Change Flag
   Shared Secret (MUST be protected from reading)

   The Server's Proxied Client table is a temporary table with object=
s:

   Proxy Address
   Proxy Signature
   Client Address
   Client Diffie-Hellman public key
   Client Nonce
   Client Signature

Moskowitz                Expires - July 2003                 [Page 4]
=0C
                            SSPP over SNMP                January 200=
3

   Server Signature
   Shared Secret (MUST be protected from reading)

   The Proxy's Client table is a temporary table with objects:

   Client Address
   Client Diffie-Hellman public key
   Client Nonce
   Client Signature
   ForwardFlag
   Proxy Signature

   A Client SHOULD keep the following objects in the MIB:

   Domain Parameters
   Diffie-Hellman key pair (the private key MUST be protected from
   reading)
   Client Address
   Nonce
   Server Address
   Server Signature
   Proxy Address
   Shared Secret (MUST be protected from reading)

2. The basic SNMP exchange

   Using SNMP for SSPP presents a few challenges that are not new to
   SNMP.  There are two processes performed by the server: generating=
 a
   Nonce and generating the shared secret along with a signature.
   Since there is no concept of a Request/Process/Response in SNMP, t=
he
   practice is to set one MIB object to poke to start the process.
   Another MIB object is polled to see the status of the process, and=
 a
   third object is queried for the answer when the status object says
   the process is done. That would be for a process that's slow
   compared to network round-trip times like the shared secret
   generation.  The Nonce can be handled by having it set at system
   start time and immediately after a shared secret is generated, so =
it
   is ready for a second SSPP exchange.

   S: Generate NonceS
   C: GET Parms, DHS, NonceS, AddressS
   C: If the Server's Parms do not match Client's, stop
      If the Public key is not valid, stop
      Else Generate NonceC, Shared Secret, SigC
   C: SET AddressC, NonceC, DHC, SigC
      (note: setting the Signature starts the process on the Server)
   S: set SigS as NULL, Generate Shared Secret
      If SigC is not valid, set SigS as "Error" and stop

Moskowitz                Expires - July 2003                 [Page 5]
=0C
                            SSPP over SNMP                January 200=
3

      Else Generate SigS, New NonceS
   C: GET SigS until not NULL
      If SigS is "Error", stop

2.1 Validating the Diffie-Hellman Public Keys

   The SSPP client MUST present DHS to some form of validation proces=
s.
   This might be in a UI as a fingerprint of the public key for visua=
l
   inspection.  A recommended fingerprint of the public key is a SHA1
   hash.  If 160 bits is too large for visual inspection an LTRUNC96
   can be used to reduce the fingerprint to 96 bits.  An X.509 Diffie=
-
   Hellman certificate may be used instead of a raw public key for
   implementations where a PKI can be deployed.

   SSPP does not require the server to validate DHC.  This presents a
   policy challenge: the server has no way of controlling which clien=
ts
   negotiate a shared secret.  SSPP does provide for a binding by the
   client between AddressC and DHC.  In controlled situations, this
   could be used in a control policy.

   The preferred control method is to allow only one client to use SS=
PP
   to directly establish a shared secret with a server.  In this
   manner, if the server rejects an SSPP exchange, this could be a
   signal that a rouge client has taken that one client slot with the
   server.  If the intended implementation can have multiple clients
   per server, the proxy method described below can be used for the
   additional clients.

3. Additional exchanges

   There are two special forms of the SSPP exchange.  One is to suppo=
rt
   changing the shared secret and the other to proxy the SSPP exchang=
e
   through a client that already has a shared secret with the server.

3.1 Changing a shared secret

   To change a shared secret, new pair of nonces are used with an
   existing set of Diffie-Hellman keys and addresses.  The exchange i=
s:

   S: Generate NonceS
   C: GET NonceS
      Generate NonceC, Shared Secret, SigC
   C: SET AddressC, NonceC, DHC, SigC
      (note: setting the Signature starts the process on the Server)
   S: If AddressC/DHC is already in the Client MIB table and the new
         NonceC is different from the prior NonceC, set Change

Moskowitz                Expires - July 2003                 [Page 6]
=0C
                            SSPP over SNMP                January 200=
3

         Flag in old table entry
      set SigS as NULL, Generate Shared Secret
      If SigC is not valid, set SigS as "Error", clear Change Flag in
         old table entry and stop
      Else Generate SigS, New NonceS and delete the old
         AddressC/DHC table entry
   C: GET SigS until not NULL
      If SigS is "Error", stop

   A successful exchange identifies the client as the owner of DHC an=
d
   through the SigC binding of AddressC to DHC, allows the server to
   delete the old shared secret and start using the new secret.

   NonceC and NonceS MUST be different with each Change.  This is to
   produce a new shared secret with the same Diffie-Hellman keys and
   Addresses.  The change in NonceC is also used as a test by the
   server to prevent a resource DOS attack against by replaying an ol=
d
   change request.

3.2 Proxying SSPP through an established Client

   When an SSPP server controls which clients it has a shared secret
   with by only accepting one SSPP exchange, additional clients can
   obtain their shared secret with the server by proxying through the
   established client.  A second signature complicates the proxied SS=
PP
   exchange.  This second signature is between the server and the pro=
xy
   to 'authorize' the exchange.  To prevent a hidden man-in-the-middl=
e
   attack by a rogue proxy, the principle signature is modified to
   include the proxy's address.  That is the client is aware of the
   proxy's role in the exchange.

   The datagram flow is:

   C           P           S

   ----------GET---------->
   <-------Response--------
   ---SET----->
               -----SET--->
   ---GET----->
   <-Response=97
   ----------GET---------->
   <-------Response--------

   The exchange and process are:

   S: Generate NonceS
   C: GET from S - Parms, DHS, NonceS, AddressS

Moskowitz                Expires - July 2003                 [Page 7]
=0C
                            SSPP over SNMP                January 200=
3

      (note the client already has AddressP)
   C: If the Server=92s Parms do not match Client's, stop
      If the Public key is not valid, stop
      Else Generate NonceC, Shared Secret, SigC
      (note SigC uses (Public key || AddressC || AddressP || NonceC))
   C: SET to P =96 AddressS, AddressC, NonceC, DHC, SigC
      (note: setting the Signature starts the process on the Proxy)
   P: set ForwardFlag to Null
      If the Proxy does not have a Shared Secret with AddressS,
         Set ForwardFlag to "Error" and stop
      Generate SigP
      (note SigP uses (Public key || AddressC || AddressP || NonceC))
   P: SET to S =96 AddressP, AddressC, NonceC, DHC, SigC, SigP
      set ForwardFlag to AddressS
      (note: setting the Signature starts the process on the Server)
   S: set SigS as NULL, Generate Shared Secret
      If the Server does not have a Shared Secret with AddressP,
         set SigS as "ErrorP" and stop
      If SigP is not valid, set SigS as "ErrorP" and stop
      If SigC is not valid, set SigS as "Error" and stop
      Else Generate SigS, New NonceS
      (note SigS uses (AddressS || AddressP || NonceS))
   C: GET from P - ForwardFlag until not NULL
      If ForwardFlag is "Error", stop
   C: GET from S - SigS until not NULL
      If SigS is "Error" or "ErrorP", stop

   The Client may start checking ForwardFlag as soon as it performs t=
he
   SET operation to the Proxy.  Since the Proxy only acts as an
   'introducer' of the client to the server, the server checks SigC f=
or
   inclusion of AddressP, and the client gets SigS directly from the
   Server, a rogue cannot insert itself between an SSPP client and
   server and force a proxied exchange.  Once a client has a shared
   secret with a server, it can directly change the shared secret and
   can itself be a proxy for another client.

4. Application of SSPP over SNMP

   SSPP over SNMP is well suited to provisioning shared secrets where
   the SSPP server is 'headless'.  That is where the server does not
   have a UI.  Traditionally these sorts of systems are either forced
   to have a server, like HTTP, implementation to support
   configuration, or SNMP is used in an insecure method to configure
   the secret, leaving it up to the deployer to deal with the risk of
   secret theft.  SSPP not only provides a secure provisioning
   methodology, it produces strong shared secrets and provides for
   managing those secrets.

Moskowitz                Expires - July 2003                 [Page 8]
=0C
                            SSPP over SNMP                January 200=
3

4.1 EXAMPLE: RADIUS Client Secret

   The RADIUS Client Secret is used to authenticate RADIUS exchanges
   between a RADIUS Server and its client(s).  With the advent of IEE=
E
   802.1x [4], RADIUS clients are proliferating in the form of 802.3
   switches and 802.11 access points.  The problems in managing the
   RADIUS Client Secret are broader than just getting a good secret a=
nd
   managing it.  This is detailed in RADIUS Client Kickstart [5], but
   the general usage is as follows.

   To protect against a rogue RADIUS server, the RADIUS client will
   only allow one server to directly setup a shared secret via SSPP.
   If the server gets an SSPP error, it can assume that a rouge serve=
r
   authenticated first, and that the client needs to be reset.  This
   will typically be a physical reset button on the client (perhaps
   part of the factory reset function).  If the RADIUS client has mor=
e
   than one RADIUS server, the additional servers will use the first
   server as their SSPP proxy.

Security Considerations

   This protocol uses an unauthenticated Diffie-Hellman exchange.  Th=
is
   is open to a Man-in-the-Middle attack.  The recommended practice f=
or
   this is that there MUST be a mechanism for the client to validate
   the server=92s Diffie-Hellman public key, or for a risk-appropriat=
e
   assurance that there is no man in the middle between the client an=
d
   server.

   The former can be addressed by client system presenting in its UI
   the fingerprint of the public key.  The operator would check the
   fingerprint with a copy obtained out-of-band (for example stamped =
on
   the server).  The later can be addressed by connecting the client
   and server with a crossover cable or by trusting the deployed
   cabling (as in a small office).

   The server is potentially open to establishing a shared secret wit=
h
   any system.  Since the SSPP server is typically a client for all
   other services, this could leave it open to attack through the
   services that the shared secret is suppose to protect.  As such a
   server might have a policy to only allow one client to use the bas=
ic
   exchange and all additional clients must use the proxy exchange.
   Typically, the first client, while the server is in factory defaul=
t
   state, will be able to use the basic exchange.  If a rogue client
   intervened before the intended client established its shared secre=
t,
   this would be discovered and the server could be reset to its
   factory default state.

Moskowitz                Expires - July 2003                 [Page 9]
=0C
                            SSPP over SNMP                January 200=
3

   The nonces are an important contributor to the shared secret
   generation.  The current cryptographic literature recommends that
   the nonces be twice the length of the desired final key.
   Additionally, it is the unique nonces that produce a unique key ea=
ch
   time the Change Secret exchange occurs.  The nonces MUST be unique
   and random.

References

                   =20
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BC=
P
      9, RFC 2026, October 1996.

   2  Moskowitz, R., "The Shared Secret Provisioning Protocol",
      Internet Draft draft-moskowitz-shared-secret-provprotocol-00.tx=
t,
      December 2002.

   3  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   4  IEEE Std 802.1X-2001, "Port-Based Network Access Control", June
      2001.

   5  Moskowitz, R., "RADIUS Client Kickstart", Internet Draft draft-
      moskowitz-radius-client-kickstart-01.txt, January 2003.

Acknowledgments

   This document is the result of the first IETF Credential
   provisioning workshop and extracted from the original RADIUS Clien=
t
   Kickstart Internet Draft.  Bob Stewart helped explain how an SNMP
   SET can trigger internal processes and how the SNMP manager polls
   the SNMP agent for objects set as a result of such a process.

Author's Addresses

   Robert Moskowitz
   TruSecure/ICSAlabs
   1000 Bent Creek Blvd, Suite 200
   Mechanicsburg, PA
   Email: [email-masked]

Moskowitz                Expires - July 2003                [Page 10]
=0C

--Boundary_(ID_kNpLygRTw8528X/RbPBi+g)--