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
- Bash the agenda
- The status of the ISO liaison
- The IAB Workshop on Security in the Internet Architecture
- 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.
- 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.
- 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?
- Access control lists:
- 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.
- Users have multiple “credits”:
- 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?
- One communications:
- Verify the origin of “message”:
- 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..
- X.500 Distinguished names:
- 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).
- Public keys and certificates:
- 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
- Rooted hierarchy ^as in PEM*:
- What is the form of names?
- Need one working group, maybe two.
Open IAB meeting
Seattle, 30 March 1994
AGENDA
Status of the ISO liaison:
What does the MOU say?
Security Workshop
Slide pack: Crocker
- Steve Crocker
- Jon Crowcroft
- Steve Deering
- Paul Francis
- Van Jacobson
- Phil Karn
- Allison Mankin
- Radia Perlman
- John Romkey
- Mike St. Johns
- 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.
- Provide a first line of defense
- Explicit list of permitted applications
- Focus energy and resources for security
- Keep up with latest threats, solutions
- 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
- Application level redirections
- IP level challenges, redirections
Group 2
Application Gateways and
Firewalls
Group 2 Members
Application Gateways are Evil
-
Application firewalls…
Application Gateways are Necessary
Application Gateways are Popular
Challenge
Is there a way to bring firewalls and gateways into the security architecture?
Two ideas explored:
Slide pack – Clark
- Not inside the end-node.
- (Want to buy a bridge?)
- Separate the network traffic into classes.
- Make sure that the bad guys are not in your class.
- Make sure each class gets some resources.
- Establishing the class.
- Mapping the packets to the class.
- We *are* putting more state in the routers.
- Explicit per
- flow setup, e.g., RSVP.
- Long
- term setup via management interface, e.g., SNMP.
- Presume some high level identifier.
- No per-packet performance issues.
- 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).
- A new field, or
- The concatenation of some old fields.
- Put that point off.
- 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.
- 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.
- 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…
- Require all routers to check the source address and discard packet if it is bogus.
- Filter out bad guys based on source address.
- Expensive
- key pair
- 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.
- 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??
- Src host/port, dest host/port, prot, etc.
- For good bandwidth sharing, aggregate traffic sources.
- For security, separate sources.
- Example — one corrupted source.
- node could make the correct decisions dynamically.
- (Lots; come to the open meeting…)
- Keeping the bad guy from joining the wrong class.
Protecting Network Resources
(Part of a)
Report from the IAB Security Workshop
February 1994
Protecting Network Resources
-
Focus on security inside the network.
Called “denial of service.”
In general, it is considered hard.
It’s easy.
Three step process
-
Q.E.D.
Sorting traffic into classes
-
Two issues:
Establishing the class implies (gasp) setup!!
But setup comes in all sorts of forms.
Setup must be secure.
Classifying the packet
-
Must use fields in the packet to map it to proper class.
Two methods:
What is the LLID?
The setup
Assuring the LLID
-
How can we be sure that “bad guys” are not putting false LLIDs in packets?
Hoping to goodness
-
We do a lot of that in the Internet.
Break the packet if its wrong
-
The most obvious example:
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)
MDx (a one way hash over the packet and a secret)
Multicast
-
Can you say “multicast”?
It makes the problem harder.
What is an LLID?
-
1) The concatenation of fields in the packet.
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.
But the right mechanism in the end
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?