IAB Minutes 1994-03-30 | Internet Architecture Board

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

Internet Architecture Board

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

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”:
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:
- Authentication for access control:
  - Access control lists:
  - Limits to wildcarding:
  - 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:
  - 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

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

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

Separate the network traffic into classes.
Make sure that the bad guys are not in your class.
Make sure each class gets some resources.

Q.E.D.

Sorting traffic into classes

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

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

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

Hoping to goodness

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

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

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

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?

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

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?

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