From owner-ietf-kink@mail.vpnc.org Sun Dec 3 17:53:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09768 for ; Sun, 3 Dec 2000 17:53:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06917 for ietf-kink-bks; Sun, 3 Dec 2000 14:42:47 -0800 (PST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06913 for ; Sun, 3 Dec 2000 14:42:45 -0800 (PST) Received: from jariws1 (a96d14hel.dial.kolumbus.fi [212.54.29.96]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id AAA18581; Mon, 4 Dec 2000 00:44:33 +0200 (EET) Message-ID: <005d01c05d7a$9dc1f020$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: , Subject: Another DOI on top of ISAKMP/IKE -- draft-arkko-map-doi-00.txt Date: Mon, 4 Dec 2000 00:44:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello. We have produced a new Internet Draft, describing how ISAKMP (and IKE to a large extent, or even KINK) could be reused in the context of protecting one non-IP protocol in mobile networks. We would appreciate getting the group's opinion on this approach. Background: =========== The 3GPP (third generation mobile network standardization forum) is working on security for their MAP protocol. MAP is a central protocol in GSM networks, and continues to be used at least for a while also in 3G networks; perhaps eventually however completely replaced by protocols such as SIP and AAA. As MAP transports sensitive data used e.g. in the authentication of GSM phones, operators are being increasingly concerned that MAP messages are transported in the clear. Now, a security mechanism has been designed to encrypt and integrity protect MAP messages. MAP runs over SS7, ad the security mechanism inserts a header between the SS7 and MAP parts of packets. The network arrangement is typically such that servers from two operator networks (visiting and home) need to talk to each other. Both IP and SS7 connectivity exists. There is a large number of operators. However, the fact that we can encrypt MAP messages is not enough by itself. We also need to configure and create MAP SAs in a scalable manner, and we need to have lifetimes for the use of the SAs. For this we need key management. Our involvement: ================ We'been working on slight modification of the IPSEC DOI in order to use ISAKMP/IKE to negotiate the MAP security associations. It turns out that IKE phase 1 can be used as-is (alternatively KINK), and that phase 2 is modified only with respect to the meaning of the SA data. For details, see the I-D http://search.ietf.org/internet-drafts/draft-arkko-map-doi-00.txt There are also other possible alternatives to implement the same functionality. A completely new and MAP-specific key management protocol over IP has also been discussed but we'd rather reuse IKE since that is used also for other purposes, is quite complete, can be deployed fast, and we could reuse implementations. An alternative protocol could also be developed solely on top of SS7. And then to the issues on which we'd like your opinion: =========================================== 1) What is your technical opinion of the approach? 2) If we decide to go for this approach within the mobile networks, how should this work proceed in the IETF world? An informational RFC? Will these be allowed while some standards track IPsec/IKE modifications are on hold? What is the process for getting a new Informational RFC? 3) Should we discuss this in San Diego? 4) What about possible future assignments of numbers from the spaces defined by a new DOI? Jari Arkko From owner-ietf-kink@mail.vpnc.org Mon Dec 11 21:57:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10084 for ; Mon, 11 Dec 2000 21:57:47 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA12420 for ietf-kink-bks; Mon, 11 Dec 2000 18:52:20 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12416 for ; Mon, 11 Dec 2000 18:52:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA22507; Mon, 11 Dec 2000 18:54:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA13883; Mon, 11 Dec 2000 18:54:21 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14901.37725.199149.11272@thomasm-u1.cisco.com> Date: Mon, 11 Dec 2000 18:54:21 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm going to bring this up tomorrow. Hopefully, this will refresh everybody. Answers inline: Walker, Jesse writes: > Mike, > > You have proposed a very good start. Here are some comments. > > a. The document needs to specify a way to identify who is indeed the > rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses > and then arbitrarily decrees the larger of the two wins; perhaps we employ > something similar.) I guess I don't understand what a tie means. The current draft says that the initiator is the only one that initiates a rekeying operation. Even if there is some clock skew where you could get into a situation where there is a collision, isn't the worst outcome two SA's for, essentially, the same traffic? If so, shouldn't there be two valid SA's, and that the old "conserative on what you send, liberal on what you receive" should apply? > > b. If KINK rekeying works like IKE rekeying, in that each peer has to > contribute nonces and the like as entropy for computing the new SA keys, it > is not evident that (2) below is correct. This is because the responder does > not know that the initiator can compute the correct SA keys for the new SA > until after it knows the peer has received its CREATE REPLY; it will be > sending traffic into a black hole if the CREATE REPLY is lost. The responder > should indeed receive on both old and new SA as (2) suggests, but perhaps it > may be better to continue sending on the old send SA until the DELETE from > the initiator arrives. Then if its CREATE REPLY never arrives, communication > can at least continue until the SA key expires. (In a two-phase commit > protocol, you don't commit until phase 2.) I believe that we can solve that by having the responder set the ACKREQ bit, which will cause the initiator to send an ACK. I definitely don't want it to be contingent on arrival of a DELETE because I think it's worthwhile to just allow the old SA to timeout. > > c. If you buy (b) above, then the initiator needs a retry timer for its > CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry > timer for CREATE REPLY (to ellicit a DELETE). s/DELETE/ACK and I agree. How about this text: In order to rekey a security association, a standard CREATE SA flow is initiated by the original initiator of the security association and it MUST set the ACKREQ to elicit a three way handshake. The old security association MAY be deleted after the new security association is created. In order to prevent ambiguity on which security association should be used, KINK mandates the following: o Receivers MUST be able to accept packets simultaneously on two security associations for otherwise identical flows. o If the CREATE REPLY has not arrived, the initiator MUST consider only the old SPI for sending and receiving traffic. o If the ACK has not arrived, the responder MUST choose the old SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following only apply if the initator desires to DELETE the old security association: o If the DELETE REPLY has not arrived, the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. For the initiator,it MUST accept traffic on either SPI, but only send on the new SPI. > e. We don't have any behavior for when an expected reply never arrives. I think I've covered the cases here. Can you find a hole? > Presumably we want to continue using the old SAs until their keys expire, Yes, unless there's proof the other side knows about the new SA. > but this is counter to the decisions discussed above about when to start > sending on the new SA. So maybe there isn't a retry limit on DELETEs? I've tweaked the above a bit; and heavens no on limitless retries :-) Mike From owner-ietf-kink@mail.vpnc.org Wed Dec 20 00:15:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04849 for ; Wed, 20 Dec 2000 00:15:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA13435 for ietf-kink-bks; Tue, 19 Dec 2000 20:52:58 -0800 (PST) Received: from cisco.com (nsm-mail2.cisco.com [171.71.236.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA13431 for ; Tue, 19 Dec 2000 20:52:57 -0800 (PST) Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA00408; Tue, 19 Dec 2000 20:55:41 -0800 (PST) Message-Id: <4.1.20001219205428.00b9fb30@nsm-mail2> X-Sender: jtrostle@nsm-mail2 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Dec 2000 20:58:05 -0800 To: ietf-kink@vpnc.org From: Jonathan Trostle Subject: 49th IETF KINK WG minutes Cc: jtrostle@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have enclosed the KINK WG meeting minutes. Please send any comments in the next two days. Thanks, Jonathan KINK WG Meeting Minutes (49th IETF at San Diego, CA, Tuesday, Dec. 12) Reported by Lisa Dussealt and Jonathan Trostle INTRODUCTION The first meeting of the KINK WG took place on December 12th, Tuesday 1-2PM at the 49th IETF. Derek Atkins and Jonathan Trostle opened the meeting with the following list of agenda items: KINK Agenda: KINK Requirements Draft - Mike Thomas KINK Key Management Draft - Mike Thomas Server Initiated Authentication - Sasha Medvinsky Artificial Phase 1 SA Key Management Draft - Tero Kivinen The immediate goals of the WG are to move the requirements draft into WG last call in January, and to proceed with standardization of a key management specification. KINK REQUIREMENTS ----------------------------------- The WG chairs plan to put the requirements draft into WG last call in January. The current requirements draft specifies that both symmetric key and public key (pkinit) clients must be supported; it was suggested that initial authentication is outside the scope of the draft. Initial authentication is mentioned in the draft since pkinit clients will not generally have a symmetric key in the Kerberos database, and the draft needs to accomodate such clients acting as servers (by using user-user authentication). The latter is a required scenario for packetcable security. There was some discussion on the list of whether the protocol must be capable of rekeying, but this seems to be outside of the scope of the work. Currently this is in the requirements document. Paul Hoffman stated that he would discuss it on the list. Derek stated that although it's a good goal to have, it's not a hard requirement. The question was raised whether there ought to be a requirement to work with IPSP. Marcus Leech stated that it should be the other way around: IPSP ought to work with the policies. KINK is an effector of these policies. Paul Hoffman mentioned that there was also interest in using other authentication protocols to fake a phase 1 SA in the same manner that Tero Kivinen's draft uses Kerberos to create the artificial phase 1 SA. For now, a general mechanism to allow other authentication mechanisms to be plugged in is out of scope. An audience member asked whether there ought to be motivation in the draft as well as requirements. In particular, more details on why RFC 2409 (IKE) is not adequate to solve the set of scenarios being targetted by the WG are desired. Derek and Mike Thomas indicated that additional concrete motivational suggestions would be welcome. Mike also suggested that the design documents explain the reasoning behind their choices. Scott Fluhrer asked about requirements for peer discovery; Jonathan Trostle replied that if you don't know who your peer is then there would be issues with respect to who you are authenticating. Mike stated that the issue appeared to be orthogonal. KINK KEY MANAGEMENT DRAFT ---------------------------------------------------- Michael Thomas led this discussion. The goals of the draft are to use Kerberos (AP_REQ and AP_REP) messages to establish an IPSEC SA using two messages (or three messages in some cases). The protocol uses a command, reply, and ack messages exchange: Initiator -------------> Responder CMD Initiator <------------ Responder REPLY Initiator -------------> Responder ACK Several message types are defined (create, delete, etc.) and these messages use a sequence of ISAKMP defined payloads (currently these payloads are defined by value in the draft). For example, the ISAKMP SA, proposal, and transform payloads are used in the create message to create a new SA. The draft also defines new messages to be used to obtain a peer's Kerberos ticket granting ticket (TGT) and to send a TGT to the peer, so that user-user authentication can be used. Using user-user authentication handles the case where the client is a pkinit client and does not have a long term key in the Kerberos database. Key derivation for the IPSEC SA is defined in the draft. The key derivation can be accomplished in the two message exchange if the responder is willing to not contribute to the keys for its outbound SA. If not, the responder sets the ack bit in the reply and the initiator will use the responder nonce as additional input into its inbound SA keys. Both initiator and responder nonces are used as input into the initiator's outbound SA keys. Mike Thomas sent some mail to the list regarding what is needed in order to rekey a security association. Jesse Walker's contention was that the text in the draft was not explicit enough, so Mike took some of his input from his last mail, and the current text is the result. Mike stated that we need to create a new SA that describes the new SA, basically for the same flow, and set up some rules for which SA to use at which times. Mike solicits comments on the WG list. Mike wants to clarify whether the initiator or responder can kill off whatever SA they like. Mike would like more examination of the key derivation material in the draft. He indicated that more work is needed on the error messages too. Mike looked at Freeswan/Pluto and hopes to have an implementation by the next IETF (March 2001). SERVER INITIATED AUTHENTICATION ---------------------------------------------------------- Sasha led the discussion here. Sasha's main concern is in a packetcable scenario where there are many clients communicating with a single server. There is a standby server that takes over when the first server fails. With the existing KINK draft user to user approach, the server must request the client's TGT and then obtain a service ticket targetted at the client. Sasha would like to send a new message, the wakeup message, from the server to the client to indicate to the client that it should obtain a service ticket for the server and then authenticate to the server. Thus some of the work is shifted from the server to the client thus improving scalability and performance of the server in this failover scenario. One concern that was expressed regarding Sasha's approach is that 3rd party denial of service attacks would be easy to launch and potentially difficult to track. In particular, a malicious peer could send wakeups (which are unauthenticated) to a large number of clients in order to bring down a given server(s) and also temporarily remove a KDC from service. Additionally, data would not flow earlier on the IPSEC SA. Alternative solutions include the sharing the ticket cache between the two servers, and pre-establishment of IPSEC SA's between the clients and the backup server. Sasha also raised some concerns regarding authorization data in tickets when using user-user authentication. Matt Hur and others disagreed with this line of reasoning, saying that the KDC could just as easily bind policy and authorization data for either the client or the server into the ticket. Additionally, some denial of service attacks might be mitigated if the client has an access control list which would prevent some wake up requests from being acted upon. Access control lists would not be applicable in all environments, and would only partially mitigate denial of service attacks in environments where they could be used. There was a desire to resolve this issue at the WG meeting rather than move the discussion to the WG list, but since roughly 10 people had read the draft, it was decided to move the discussion to the list and obtain consensus there. ARTIFICIAL KERBEROS IKE SA DRAFT ----------------------------------------------------------- Tero Kivinen presented his draft for KINK key management: draft-ietf-kink-ike-over-kkmp-00.txt. The draft uses a newly defined Kerberos payload to exchange the AP_REQ and AP_REP messages. At that point, the two peers share the Kerberos session key which is used to create the following shared state (corresponding to a successful phase 1 exchange): cookies, SKEYID for key material, and IV. Everything that is in IKE phase 2 can be supported: new group mode, quick mode, etc. Tero claimed that his draft is quite simple to implement. Tero has implemented IKE, and he stated that his new draft would take one day to implement. Tero also stated that any new features or improvements to phase 2 IKE could also be reflected in his work since it builds upon IKE. Tero noted that he needed to add the capability for Kerberos user-user messages. The Kerberos payload message in his draft could be used to transport KRB_TGT_REQ and KRB_TGT_REPLY messages, in order to support user to user messages. An audience member questioned the possibility of replays. Tero stated that if the SA is already valid, then they see there is duplicate SA numbers so they drop the packet immediately. When it doesn't see any traffic coming through, it doesn't do any expensive calculation. Derek pointed out that the Kerberos authenticator contains a timestamp to prevent replays. Another audience member also asked whether the Kerberos session key was big enough; the response was that the key is typed so it will be the right size for whatever crypto algorithm is being used.