NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Jeffrey Schiller <jis@mit.edu>
General Discussion:ipsec@lists.tislabs.com
To Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec
Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.
The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies.
Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol.The protocol will be based on the ISAKMP/Oakley work begun in:
draft-ietf-ipsec-isakmp-05.txt,
draft-ietf-ipsec-oakley-01.txt, and
draft-ietf-ipsec-isakmp-oakley-00.txt
A follow on work item may incorporate mechanisms based on SKIP as defined in:
draft-ietf-ipsec-skip-07.txt
and related documents.Flexibility in the protocol will allow eventual support of Key Distribution Centers (KDC), such as are used by Kerberos.
Done |
|
Post as an Internet-Draft the IP Security Protocol. |
Done |
|
Post as an Interenet-Draft the specification for Internet key management. |
Done |
|
Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. |
Done |
|
Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH). |
Done |
|
Submit revised Interent-Drafts for ESP, AH, and IP Security Architecture. |
Done |
|
Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards. |
Dec 96 |
|
Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards. |
Done |
|
Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard. |
Done |
|
Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. |
Jul 97 |
|
Submit IKMP to IESG for consideration as a Draft Standard. |
· DHCPv4 Configuration of IPSEC Tunnel Mode
· IPsec DOI Textual Conventions MIB
· ISAKMP & IKE Extensions Methods
· ISAKMP DOI-Independent Monitoring MIB
· Content Requirements for ISAKMP Notify Messages
· Fixing IKE Phase 1 & 2 Authentication HASH
· The Candidate AES Cipher Algorithms and Their Use With IPsec
· IKE Authentication Using ECDSA
RFC |
Status |
Title |
RFC1828 |
PS |
IP Authentication using Keyed MD5 |
RFC1829 |
PS |
The ESP DES-CBC Transform |
RFC2104 |
HMAC: Keyed-Hashing for Message Authentication | |
RFC2085 |
PS |
HMAC-MD5 IP Authentication with Replay Prevention |
RFC2401 |
PS |
Security Architecture for the Internet Protocol |
RFC2410 |
PS |
The NULL Encryption Algorithm and Its Use With IPsec |
RFC2411 |
IP Security Document Roadmap | |
RFC2402 |
PS |
IP Authentication Header |
RFC2412 |
The OAKLEY Key Determination Protocol | |
RFC2451 |
PS |
The ESP CBC-Mode Cipher Algorithms |
RFC2403 |
PS |
The Use of HMAC-MD5-96 within ESP and AH |
RFC2404 |
PS |
The Use of HMAC-SHA-1-96 within ESP and AH |
RFC2405 |
PS |
The ESP DES-CBC Cipher Algorithm With Explicit IV |
RFC2406 |
PS |
IP Encapsulating Security Payload (ESP) |
RFC2407 |
PS |
The Internet IP Security Domain of Interpretation for ISAKMP |
RFC2408 |
PS |
Internet Security Association and Key Management Protocol (ISAKMP) |
RFC2409 |
PS |
The Internet Key Exchange (IKE) |
RFC2857 |
PS |
The Use of HMAC-RIPEMD-160-96 within ESP and AH |
IPsec WG Minutes
Monday, March 19, 2000
Taken by Barbara Fraser
Agenda Bashing
IPSEC MIB documents: These documents will be going to wg last call in two weeks. They've been posted for awhile and there has been little or no discussion on them. Ted Ts'o urged those who did have comments to send them in asap.
John Iannodis: pointed out that there is a 3GPP draft out that folks might be interested in
IPSEC and IPV6
1. Jari Arkko presented the draft on Effects on ICMPv6 on IKE and IPsec Policies. This draft covers a problem with circular icmp traffic.
2. Jari Arkko also presented the draft on Manual SA Configuration for IPv6 Link Local Messages. Analyzed of icmpv6 security implications. Table presented that showed control functions against weak and strong attackers at low and high levels. DoS for weak attackers under higher layer security; man in the middle, spying, and impersonation for all attackers under no higher layer security; identity selection in all situations, if stateful... He presented possible ways to reduce the configuration effort which was about twice the SAs as the number of nodes.
Comments: Dan McDonald draft on link shared secret, presented in Adelaide to the v6 group and it could be dragged back up to help with the manual configuration.
Steve Kent suggested that we need a more complete story in order to motivate people.
We'll need more discussion on the mailing list to see how to proceed with both of these.
3. Tissa Senevirathne presented draft-tsenevir-smpls-doi-00.txt draft-tsenevir-smpls-doi-00.txt draft-tsevevir-smpls-oo.txt
MPLS is considered as secure as atm and frame relay but there is no evidence that these aren't being attacked. Currently have multiple encapsulation: foo/IP/IPsec/MPLS/...
Payload encapsulation formats differ in that the next header field is not being used.
For the SA, they're using IKE over RSVP (no additional control channel needed and a new RSVP object defined) and separate IKE channel (allows scaling, simpler implementation, but may not provide PFS)
Comment that MPLS security is not an IP protocol and hence it doesn't belong at the IETF. Tissa replied that this is the sub-IP layer that the IETF is forming. Tissa also said there wasn't much security expertise present in the MPLS wg. Ted said that a similar issue has come up with IPv6 addressing which will be discussed in SAAG.
Tissa: is it ok to run IKE over RSVP? Suggested that he raise this question at the SAAG meeting.
A. D. Keromytis, On the Use of SCTP with IPsec draft: SCTP is a Transport protocol that supports multiple addresses for source and destination. Covered the issues related to IPsec.
SAs will need to be specified by a set of addresses SPD: processing for the entries will have to support sets of addresses IKE Phase 2 IDs: a couple of problems with several solutions which the working group will need to agree on.
IKE phase I IDs and certificates: if using certs, it's possible for two hosts to verify each other's addresses with the info in the certificates. Certs will support multiple addresses but they'll need to be handled.
The draft makes suggestions about changes to the architecture as well as to IKE. Only a handful of people said they had enough understanding in order to get consensus at this point. Ted asked that A.D. post a clear list of issues to the list for discussion.
IPSEC and NAT
William Dixon presented draft-stenberg-ipsec-nat-traversal-02 and draft-huttunen-ipsec-esp-in-udp-01.
The two groups have been working together to arrive at a consensus proposal. Of course the first question is if people think NAT will even be needed with IPv6.
Question: Is the internal IP address being exposed a legitimate security concern? The current draft it can be actively queried by active negotiation, can be discovered by man in the middle; and using discover payload of IP address hash makes IP discoverable passively.
UDP encapsulation done during phase 2; encapsulation attribute expanded to allow for new UDP encap option but would like a better answer in son of IKE attribute negotiation; send original real IP address in IKE notify
Described what the encapsulation would look like. See draft.
What about AH? It gets very messy and the authors would rather have agreement that having IP address info in the header is ok.
Keepalives: for the purpose of keeping the NAT mapping alive, it's not the same as the IKE keepalives discussion.
The intellectual property issues are resolved so the drafts are moving forward. Question: what about the patent posted in Europe? SSH has one patent and has a new one coming that is about determining if a NAT is present. Request that the patent application be posted to the list. Answer: it's on the IETF web page.
Is the reason we have the cookie mechanism to have 1 rather than 2 ports? Answer was yes.
New draft with new name will come out in the next couple of weeks.
Son of Ike discussion
Ted introduced the discussion with the following ground rules: This is to fix bugs in IKE, not an invitation to add arbitrary features. While we may be talking about bumping major versions numbers, there is a lot of installed base so people will be supporting old IKE and new IKE. Changes will need to be implementation preserving. About twice as many folks felt we did need implementation preservation than not.
Dan Harkins presented his ideas for Son of IKE
Combine the three into a new draft and deprecate the other three. Why? A lot of folks just don't like IKE, unnecessarily long and hard to read. Duplicate verbage in the docs would be eliminated.
IKE has received some crypto analysis and no flaws (unlike WEP and PPTP) and there is wide industry acceptance. It does work.
Even though it's very flexible, it hasn't been used so the question is are all these layers necessary. To combine them, we lose the layer violations, less ambiguous and more internally consistent, no repeated text. We also lose the general framework.
New group mode?
aggressive mode?
ISakmp exchange...
Advancements in the state of the art (out with DES and in with AES); suggestions for protocol improvement can be considered.
Discussion: more interoperabiity among deployed systems is a main objective.
smb: It will probably simplify the document even though it may not reduce the code base.
There is a risk in characterizing the issues. At the last bakeoff there were still a number of IKE issues. Clarity, extensibility. Taro sent the issues to the list after the last bakeoff.
The problem is complexity. Refocus by focusing on the state machine and the bulk of the problems will go away.
Rewriting will not solve some of the problems so why don't we leave IKE as it is now with a strict set of problems and start over with a new protocol.??? didn't understand this.
Concern that if Dan takes out everything that is problematic, there will be problems. Instead, keep it in but add text that says why it's there and what the issues are.
AD: even if we did nothing else than clarify the docs we would have done well. Starting over may not be a good idea and we don't have enough people in the room who are developers to be able to determine this today.
Reduce some of the choices that nobody uses; discuss the core set of options that folks are really using. There are areas that are underspecified, e.g., negotiating lifetimes. We could document the types of things that are giving us headaches.
Keepalives and XAUTH were sort of shoehorned in, but we might be able to solve these problems with better solutions.
Ted: There are have been various strawman proposals for heartbeats, birth certificates, death certificates... For some of these narrow areas it might make sense to use multiple IDs to flesh out the ideas and approaches. Once baked it can be incorporated into the new IKE draft.
Someone to keep track of all the places where we've made a change from the original IKE. Could be an ID, or an internal working group document. Ted went through the items that were posted to the list in the past couple of days.
Comment that SCTP be addressed as a mod to current IKE so that it doesn't get stalled behind the son of IKE work.
Suggestion to advance the elliptic curve draft and the config mode draft to solve the IANA number issue? Ted: no wg consensus.
Comment suggesting that we look forward when making changes.