Internet Architecture Board

RFC2850

IAB Minutes 1994-03-30

Home»Documents»Minutes»Minutes 1994»IAB Minutes 1994-03-30

Internet Architecture Board

    The open IAB meeting was devoted to two topics: a presentation of the progress of the ISO liaison and a report on the IAB Workshop on Security in the Internet Architecture.

    Christian Huitema presented the progress of the liaison discussion with ISO. A dedicated mailing list, i2i@sophia.inria.fr, was established in December 93; 80 participants have joined and approximately 100 messages have been exchanged. Consensus has almost been reached on the form of the liaison: mutual recognition of standards, information on work programs, information sharing, and collaborative efforts. On this basis, ISO/IEC JTC1 has approved the establishment of a category A liaison between IETF/IAB/ISOC and the subcommittee JTC1/SC6. Other committees are supposed to follow<-on later. The project of ``Memorandum of Understanding'' was presented and discussed during the meeting.

    The results of the IAB Workshop on Security in the Internet Architecture were presented by the leaders of the retreat’s working groups: Christian Huitema, Steve Crocker and Dave Clark, who presented the reflections on authentication strategies, firewalls, and the linkage between high-level authentication and low-level identification of flows to fight denial of service attacks.


Slide Pack – Huitema

    Internet Architecture Board
    Open IAB meeting
    Seattle, 30 March 1994

    AGENDA

    • Bash the agenda

    • The status of the ISO liaison

    • The IAB Workshop on Security in the Internet Architecture

    Status of the ISO liaison:

    • I2I@sophia.inria.fr:
      • Set up 13 December 1993
      • 80 participants
      • 300 messages
      • the apparence of convergency.
    • Meeting of JTC1, February 1994 :
      • Agreed on class A liaison
      • Between JTC1/SC6 and ISOC
      • Need to prepare an MOU.
    • First version of MOU:
      • Sent the 22 March to the I2I list
      • Few comments received
      • Second version sent 25 March.

    What does the MOU say?

    • Mutual Recognition of Standards:
      • Quote the other organization’s work
      • External reference, not “stamping”
      • Maintenance by the originator.
    • Information on work programs:
      • Send list of working groups
      • Complete with RFC, drafts, achievements
      • Every 6 months.
    • Information sharing
      • send list of publications
      • place technical material on line, accessible.
    • Collaborative efforts:
      • Joint meetings of WG allowed
      • may hold joint workshops.

    Security Workshop

    • Working group “1″:
        Christian Huitema, INRIA
        Steve Bellovin, AT&T
        Bob Braden, ISI
        John Curran, NEARNET
        Phill Gross, ANS
        Stev Knowles, FTP Software
        Barry Leiner, USRA
        Paul Mockapetris, ISI
        Yakov Rekhter, IBM
        Dave Sincoskie, Bellcore

    • Summary of retreat:
      • Look at proposed scenario

      • Investigate various avenues:
        • Authentication vs. Privacy
        • Privacy without authentication
          (TCP encryption option?)
        • Use of DNS.
      • Reflexion on firewalls:
        • Authentication vs. Authorization
        • Concur with other groups.
      • Study the authentication service.
    • AN AUTHENTICATION SERVICE?
      • Verify the origin of “message”:
        • One time passwords
        • Access to a FIrewall..

          basis for “access control”, authorization.

      • What shall we name:

          domain names: sophia.inria.fr
          machine names: jupiter.inria.fr
          service names: www.sophia.inria.fr
          users: huitema@sophia.inria.fr
          processes: p112.huitema@sophia.inria.fr, p112.sophia.inria.fr
          URL: http://www.sophia.inria.fr:222/tmp/foobar

      • Authentication for access control:
        • Access control lists:
            huitema@sophia.inria.fr
            *@sophia.inria.fr
            *.inria.fr
            *.fr
        • Limits to wildcarding:
            “member of the IAB?”
        • The “distinguished name” approach:
          • An user has one name
          • Capacities are attached to this name
          • Cryptographic protections.
        • The critic of distinguished names:
          • Validate the name
          • Validate the “capacity”
            => requires 2 validations
            =>two entities to trust
            => displays the name.
        • A “credit card” alternative?
      • There is no such thing as a name:
        • Users have multiple “credits”:
          • Several bank accounts
          • Driver licence
          • Frequent _yer
          • professional ID
          • Passport.
        • User could have multiple names:
          • Only one validation
          • Allows wild carding
          • Allow more privacy.
        • A name is a relation:
            huitema@sophia.inria.fr
            huitema@iab.isoc.org
            123456789@cards.amex.com
        • A relation is easier to check:
          • Only one name to check
          • Top certi*cate is known
          • Widcarding is easy.
      • Chosing your credential:
        • One communications:
          • Many resources
          • Different controls
          • Different tokens, names.
        • Cannot pass “all the credentials”:
          • Too bulky (messages)
          • Too slow (walk through the list)
          • Too informative (privacy).
          • Need to chose a name:
            • By the user?
            • Resource manager advertize its list?
            • A generic problem of path finding.
        • Start with one name only?
    • Designing the authentication service:
      • What is the form of names?
        • X.500 Distinguished names:
          • Bulky, No name service, Ugly..
        • DNS names:
          • Too short, alphabet soup..
      • What technology should we use:
        • Public keys and certificates:
          • Patented, computing requirement.
          • Recent annouces by RSADIR?
        • Symmetric keys (DES, MD5):
          • No protection against repudiation
          • Real time message exchanges.
        • Authentication only (export contol).
      • What kind of networking architecture:
        • Rooted hierarchy ^as in PEM*:
          • Difficult to deploy, “big brother”..
        • Bottom up growth (as in PGP):
          • The “friends and family” of security
    • Need one working group, maybe two.

Slide pack: Crocker


    Group 2

    Application Gateways and
    Firewalls


    Group 2 Members

    • Steve Crocker
    • Jon Crowcroft
    • Steve Deering
    • Paul Francis
    • Van Jacobson
    • Phil Karn
    • Allison Mankin
    • Radia Perlman
    • John Romkey
    • Mike St. Johns

    Application Gateways are Evil

      Application firewalls…

      • restrict IP connectivity and thus damage net
      • restrict new applications
      • require double login
      • don’t fit within the architecture
      • are potential single points of failure
      • are potential performance bottlenecks
      • promote sloppier administration of “protected” hosts
      • don’t provide complete protection, e.g., letter bombs, etc.

    Application Gateways are Necessary

    • Provide a first line of defense
    • Explicit list of permitted applications
    • Focus energy and resources for security
    • Keep up with latest threats, solutions

    Application Gateways are Popular

    • At least four offerings
      • Raptor Eagle
      • DEC Seal
      • ANS Interlock
      • TIS Firewall toolkit (FWTK)
    • General perception by business that open connection to Internet is poor practice
    • >1,000 retrievals of TIS FWTK in less than 6 months

    Challenge

      Is there a way to bring firewalls and gateways into the security architecture?

    Two ideas explored:

    • Application level redirections
    • IP level challenges, redirections

Slide pack – Clark


    Protecting Network Resources

    (Part of a)
    Report from the IAB Security Workshop

    February 1994


    Protecting Network Resources

      Focus on security inside the network.

      • Not inside the end-node.

      Called “denial of service.”
      In general, it is considered hard.
      It’s easy.

      • (Want to buy a bridge?)

    Three step process

    1. Separate the network traffic into classes.
    2. Make sure that the bad guys are not in your class.
    3. Make sure each class gets some resources.
      Q.E.D.

    Sorting traffic into classes

      Two issues:

      • Establishing the class.
      • Mapping the packets to the class.

      Establishing the class implies (gasp) setup!!

      • We *are* putting more state in the routers.

      But setup comes in all sorts of forms.

      • Explicit per
      • flow setup, e.g., RSVP.
      • Long
      • term setup via management interface, e.g., SNMP.

      Setup must be secure.

      • Presume some high level identifier.
      • No per-packet performance issues.

    Classifying the packet

      Must use fields in the packet to map it to proper class.
      Two methods:

      • Put a bunch of identifier in the packet, one for each relevant point in the path.
      • Put one identifier in the packet, and teach each relevant point about it.
      • The latter is the only way to go: Low level identifier (LLID).

      What is the LLID?

      • A new field, or
      • The concatenation of some old fields.
      • Put that point off.

    The setup

    • mechanistically,
      Someone (sender, receiver, manager):

      • Gets the LLID.
      • Binds that LLID to some state in a router.
    • Can bind different state to same LLID in different router.
      • LLID must be “fine
      • grained.”
      • Trust in LLID must meet the max of requirements.
      • Duration of LLID must match duration of setup.

    Assuring the LLID

      How can we be sure that “bad guys” are not putting false LLIDs in packets?

      1. Hope to goodness.
      2. Use fields in packet for LLID that cannot be changed without breaking things.
        • Sometimes works, sometimes not.
      3. Add an authenticator to the packet.

    Hoping to goodness

      We do a lot of that in the Internet.

      • Multicast religion — anyone can send to an m-cast group.
        • “Wild card” in source.
      • Alternative religion — defend me from bad guys sending to an M-cast group.
        • List the good guys.
        • Black-ball the bad guys.
      • But if the bad guy puts the wrong source address in an m-cast packet…

    Break the packet if its wrong

      The most obvious example:

      • Require all routers to check the source address and discard packet if it is bogus.
      • Filter out bad guys based on source address.

      This takes a lot of thought to see if it actually helps.

    Add an authenticator to the packet

      PK-lite (some public key signature over the packet)

      • Expensive
      • key pair

      MDx (a one way hash over the packet and a secret)

      • Cheaper than PK-lite
      • Shared secret key.
        • Any router can be a sender (any router can resend, anyway)
        • Pick a LLID from a sparse space.
          • Real cheap.
          • Any passive wire tapper can be a sender.

    Multicast

      Can you say “multicast”?
      It makes the problem harder.

      • Recipient may not (want to) know all the sources.
      • So, recipient does not know (in advance) all the LLIDs.
      • Must the recipient enumerate all the sources?
        • Bad idea??

    What is an LLID?

      1) The concatenation of fields in the packet.

      • Src host/port, dest host/port, prot, etc.

      2) An explicit new field (like a flow id).

        2a) a sparse field for authentication

      It is NOT just an address. Addresses and LLIDs are different.

    Putting packets in classes

      We are building routers that sort packets into classes.
      We are building routers that assign resources to classes.
      Are these the same classes as for security?
      Perhaps not quite. Issue is granularity of classes.

      • For good bandwidth sharing, aggregate traffic sources.
      • For security, separate sources.
      • Example — one corrupted source.

      But the right mechanism in the end

      • node could make the correct decisions dynamically.

    Why is this possible?

      We are sorting traffic into classes anyway, to support real time and other QoS.
      We are proposing routers that allocate resources to classes for the same reason.
      So, at last, the basic building blocks are there.
      What is missing?

      • (Lots; come to the open meeting…)
      • Keeping the bad guy from joining the wrong class.