From david.black@emc.com Mon May 13 15:33:06 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E05621F8E9D for ; Mon, 13 May 2013 15:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFx6GVWEj5xE for ; Mon, 13 May 2013 15:33:05 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id B1A9D21F92FC for ; Mon, 13 May 2013 15:33:00 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DMWw4v028192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 May 2013 18:32:59 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Mon, 13 May 2013 18:32:39 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4DMWcFf032269 for ; Mon, 13 May 2013 18:32:39 -0400 Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Mon, 13 May 2013 18:32:38 -0400 From: "Black, David" To: "storm@ietf.org" Date: Mon, 13 May 2013 18:32:37 -0400 Thread-Topic: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence Thread-Index: AQHOUCCmBLbvJmEKmEyg4la0xaxgjpkDszPw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712953BA690@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] FW: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 22:33:06 -0000 Please give some thought to participating in this year's NomCom. This is a great way to contribute to the IETF. Thanks, --David -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of Mankin, Allison Sent: Monday, May 13, 2013 5:27 PM To: ietf-announce@ietf.org Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first se= ntence The IETF nominating committee (nomcom) process for 2013-14 has begun. The=20 IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y random way from a pool of volunteers. The more volunteers, the better chanc= e we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. =20 =20 Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time thi= s email announcement goes out to start the solicitation of volunteers. The fi= ve meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86. If you qualify, please volunteer. However, much as we want this, before yo= u=20 decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. =20 =20 The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect=20 requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to=20 candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)= =20 June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: =20 // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] =20 =20 // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF!=20 I will be publishing a more detailed target timetable, as well as details=20 of the randomness seeds to be used for the RFC 3797 selection process,=20 within the next couple weeks. =20 Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the=20 address given.=20 From david.black@emc.com Wed May 29 07:43:51 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F51E21F9007; Wed, 29 May 2013 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J-yaSf0WNTd; Wed, 29 May 2013 07:43:45 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D909321F8D31; Wed, 29 May 2013 07:43:39 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEhRAi023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 10:43:38 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 10:43:07 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEh6qB008150; Wed, 29 May 2013 10:43:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Wed, 29 May 2013 10:43:05 -0400 From: "Black, David" To: "kitten@ietf.org" Date: Wed, 29 May 2013 10:43:04 -0400 Thread-Topic: Kerberos Considerations for iSCSI Authentication Thread-Index: Ac5cetOj5lUqLotRRMCSm1pg3XhHmw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "storm@ietf.org" Subject: [storm] Kerberos Considerations for iSCSI Authentication X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:43:51 -0000 The storm WG's consolidated iSCSI draft (draft-ietf-storm-iscsi-cons-08) has a few issues from IESG evaluation that need attention, one of which is that some security considerations text for Kerberos needs to be added. I don't know of any Kerberos authentication for iSCSI that's currently in use, although it has been implemented at least once, and hence the decision has been made to retain its specification as part of the iSCSI protocol update in this draft. I'd appreciate comments on the following text, and please at least cc: me (preferably also the storm mailing list). Note that KRB_AP_REQ and KRB_AP_REP are the client message and server's response message as defined in RFC 4120. I do want to head off one area of comments - please send any "you should use GSS-API" comments to /dev/null. iSCSI was specified to use Kerberos w/o GSS-API a long time ago, so GSS-API for iSCSI would be a new iSCSI authentication mechanism that should be in a separate draft, as opposed to this update (which is already long enough). ------------------ 9.2.3 Kerberos Considerations for iSCSI Authentication =20 iSCSI uses Kerberos via "bare" tokens - i.e. does not use GSS-API ([RFC4121= ]) - for authenticating the two Kerberos principals during the iSCSI Login proce= ss. This implies that iSCSI implementations supporting the KRB5 AuthMethod (Section 12.1) are directly involved in the Kerberos protocol. Specifically= , the following actions MUST be performed as specified in [RFC4120]: - Target MUST validate the KRB_AP_REQ to ensure that the initiator can be trusted - When mutual authentication is selected, the initiator MUST validate KRB_AP_REP to determine the outcome of mutual authentication =20 As Kerberos V5 is capable of providing mutual authentication, implementatio= ns SHOULD support mutual authentication by default for login authentication. Note however that Kerberos authentication only assures that the server (iSCSI target) can be trusted by the Kerberos client (initiator) and vice-versa; an initiator should employ appropriately secured service discovery techniques (e.g. iSNS, Section 4.2.7) to ensure that it is talking to the intended target principal. ------------------ Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Wed May 29 17:18:59 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2A21F955C; Wed, 29 May 2013 17:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBOjMeDLdagf; Wed, 29 May 2013 17:18:53 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4862E21F949D; Wed, 29 May 2013 17:18:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4U0IhMx008012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 20:18:49 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 20:18:34 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4U0IX1V029834; Wed, 29 May 2013 20:18:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 29 May 2013 20:18:33 -0400 From: "Black, David" To: Nico Williams Date: Wed, 29 May 2013 20:18:33 -0400 Thread-Topic: [kitten] Kerberos Considerations for iSCSI Authentication Thread-Index: Ac5cqXI/5wO30C/LRfeOZY+V+aHxvgAIIP7Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C7C2@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "kitten@ietf.org" , "storm@ietf.org" Subject: Re: [storm] [kitten] Kerberos Considerations for iSCSI Authentication X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:18:59 -0000 TmljbywNCg0KVGhhbmsgeW91IGZvciB0aGUgcHJvbXB0IGFuZCB1c2VmdWwgcmV2aWV3Lg0KDQpD b21tZW50cyBpbmxpbmUgLi4uDQoNClRoYW5rcywNCi0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOaWNvIFdpbGxpYW1zIFttYWlsdG86bmljb0BjcnlwdG9u ZWN0b3IuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAyOSwgMjAxMyA0OjE2IFBNDQo+IFRv OiBCbGFjaywgRGF2aWQNCj4gQ2M6IGtpdHRlbkBpZXRmLm9yZzsgc3Rvcm1AaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtraXR0ZW5dIEtlcmJlcm9zIENvbnNpZGVyYXRpb25zIGZvciBpU0NTSSBB dXRoZW50aWNhdGlvbg0KPiANCj4gT24gV2VkLCBNYXkgMjksIDIwMTMgYXQgOTo0MyBBTSwgQmxh Y2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPiB3cm90ZToNCj4gPiBJIGRvIHdhbnQgdG8g aGVhZCBvZmYgb25lIGFyZWEgb2YgY29tbWVudHMgLSBwbGVhc2Ugc2VuZCBhbnkgInlvdQ0KPiA+ IHNob3VsZCB1c2UgR1NTLUFQSSIgY29tbWVudHMgdG8gL2Rldi9udWxsLiAgaVNDU0kgd2FzIHNw ZWNpZmllZCB0byB1c2UNCj4gPiBLZXJiZXJvcyB3L28gR1NTLUFQSSBhIGxvbmcgdGltZSBhZ28s IHNvIEdTUy1BUEkgZm9yIGlTQ1NJIHdvdWxkIGJlIGENCj4gPiBuZXcgaVNDU0kgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtIHRoYXQgc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZHJhZnQsDQo+ID4g YXMgb3Bwb3NlZCB0byB0aGlzIHVwZGF0ZSAod2hpY2ggaXMgYWxyZWFkeSBsb25nIGVub3VnaCku DQo+IA0KPiBPdGhlciBjb21tZW50cyB0byBoZWFkIG9mZjoNCj4gDQo+ICAtIEtlcmJlcm9zIDwt PiBJUHNlYyBiaW5kaW5nPyAgbmV2ZXIgbWluZDsgd2UgZmFpbGVkIHRvIGdldCB1cHRha2Ugb24g UkZDNTY2MC4NCg0KSSdtIGFmcmFpZCBzbyAuLi4gc29ycnkuDQoNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0NCj4gPg0KPiA+IDkuMi4zIEtlcmJlcm9zIENvbnNpZGVyYXRpb25zIGZvciBpU0NTSSBB dXRoZW50aWNhdGlvbg0KPiA+DQo+ID4gaVNDU0kgdXNlcyBLZXJiZXJvcyB2aWEgImJhcmUiIHRv a2VucyAtIGkuZS4gZG9lcyBub3QgdXNlIEdTUy1BUEkNCj4gKFtSRkM0MTIxXSkgLQ0KPiA+IGZv ciBhdXRoZW50aWNhdGluZyB0aGUgdHdvIEtlcmJlcm9zIHByaW5jaXBhbHMgZHVyaW5nIHRoZSBp U0NTSSBMb2dpbg0KPiBwcm9jZXNzLg0KPiANCj4gcy90b2tlbnMvUERVcy8gIChhbmQgZGVmaW5l IHRoZSB0ZXJtOiBQcm90b2NvbCBEYXRhIFVuaXQpLiAgT3IgYmV0dGVyOg0KPiANCj4gTkVXOg0K PiAgICBpU0NTSSB1c2VzIHJhdyBLZXJiZXJvcyBWNSBbUkZDNDEyMF0gZm9yIGF1dGhlbnRpY2F0 aW5nIGEgY2xpZW50DQo+IChpU0NTSSBpbml0aWF0b3IpIHByaW5jaXBhbCB0byBhIHNlcnZpY2Ug KGlTQ1NJIHRhcmdldCkgcHJpbmNpcGFsLg0KPiBOb3RlIHRoYXQgaVNDU0kgZG9lcyBub3QgdXNl IHRoZSBHZW5lcmljIFNlY3VyaXR5IFNlcnZpY2VzIEFwcGxpY2F0aW9uDQo+IFByb2dyYW1taW5n IEludGVyZmFjZSAoR1NTLUFQSSkgW1JGQzI3NDNdIG5vciB0aGUgS2VyYmVyb3MgVjUgR1NTLUFQ SQ0KPiBzZWN1cml0eSBtZWNoYW5pc20gW1JGQzQxMjFdLg0KDQorMSBvbiB0aGUgbmV3IHRleHQg LSB3ZSdsbCB0YWtlIGl0Lg0KIA0KPiA+IFRoaXMgaW1wbGllcyB0aGF0IGlTQ1NJIGltcGxlbWVu dGF0aW9ucyBzdXBwb3J0aW5nIHRoZSBLUkI1IEF1dGhNZXRob2QNCj4gPiAoU2VjdGlvbiAxMi4x KSBhcmUgZGlyZWN0bHkgaW52b2x2ZWQgaW4gdGhlIEtlcmJlcm9zIHByb3RvY29sLiBTcGVjaWZp Y2FsbHksDQo+ID4gdGhlIGZvbGxvd2luZyBhY3Rpb25zIE1VU1QgYmUgcGVyZm9ybWVkIGFzIHNw ZWNpZmllZCBpbiBbUkZDNDEyMF06DQo+IA0KPiBUaGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIGFi b3ZlIHBhcmEgc2F5cyBub3RoaW5nIHRvIG1lIDooICBSZW1vdmUgaXQ/DQo+IA0KDQpTdXJlLg0K DQo+ID4gICAgICAgICAgIC0gVGFyZ2V0IE1VU1QgdmFsaWRhdGUgdGhlIEtSQl9BUF9SRVEgdG8g ZW5zdXJlIHRoYXQgdGhlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgaW5pdGlhdG9yIGNh biBiZSB0cnVzdGVkDQo+ID4gICAgICAgICAgIC0gV2hlbiBtdXR1YWwgYXV0aGVudGljYXRpb24g aXMgc2VsZWN0ZWQsIHRoZSBpbml0aWF0b3INCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICBN VVNUIHZhbGlkYXRlIEtSQl9BUF9SRVANCj4gPiAJCQkJCXRvIGRldGVybWluZSB0aGUgb3V0Y29t ZSBvZiBtdXR1YWwgYXV0aGVudGljYXRpb24NCj4gDQo+IFllcy4gIChBc3N1bWluZyB0aGVyZSdz IHRleHQgZWxzZXdoZXJlIHNheWluZyB0aGF0IHRoZXNlIFBEVXMgaGF2ZSB0bw0KPiBiZSBzZW50 IGFuZCByZWNlaXZlZCBpbiBvcmRlciB0byB2YWxpZGF0ZSB0aGVtIDopDQoNClllcywgdGhlcmUg aXMsIGFuZCB3ZSdsbCBkb3VibGUtY2hlY2suDQoNCj4gPiBBcyBLZXJiZXJvcyBWNSBpcyBjYXBh YmxlIG9mIHByb3ZpZGluZyBtdXR1YWwgYXV0aGVudGljYXRpb24sIGltcGxlbWVudGF0aW9ucw0K PiA+IFNIT1VMRCBzdXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbiBieSBkZWZhdWx0IGZvciBs b2dpbiBhdXRoZW50aWNhdGlvbi4NCj4gDQo+IElzIHRoZXJlIGEgcmVhc29uIG5vdCB0byBtYWtl IHRoaXMgYSBNVVNUPw0KDQpZZXMsIGEgbG90IG9mIGRlcGxveWVkIGlTQ1NJIGF1dGhlbnRpY2F0 aW9uIGlzIG9uZS13YXkgLSBpbml0aWF0b3JzIChob3N0KQ0KYXV0aGVudGljYXRlIHRvIHRhcmdl dHMgKHN0b3JhZ2UpLCBidXQgbm90IHZpY2UtdmVyc2E7IGZvcmNpbmcgZGVmYXVsdHMNCnRvIG5l dmVyIG1hdGNoIGNvbW1vbiB1c2FnZSBoYXMgc29tZSBhbmFsb2dpZXMgdG8gdHJ5aW5nIHRvIHRl YWNoIGEgcGlnDQp0byBzaW5nIC4uLiBvbmUgZ2V0cyBubyBtdXNpYyBhbmQgb25seSBzdWNjZWVk cyBpbiBhbm5veWluZyB0aGUgcGlnIDotKS4NCg0KPiA+IE5vdGUgaG93ZXZlciB0aGF0IEtlcmJl cm9zIGF1dGhlbnRpY2F0aW9uIG9ubHkgYXNzdXJlcyB0aGF0IHRoZSBzZXJ2ZXINCj4gPiAoaVND U0kgdGFyZ2V0KSBjYW4gYmUgdHJ1c3RlZCBieSB0aGUgS2VyYmVyb3MgY2xpZW50IChpbml0aWF0 b3IpIGFuZA0KPiA+IHZpY2UtdmVyc2E7IGFuIGluaXRpYXRvciBzaG91bGQgZW1wbG95IGFwcHJv cHJpYXRlbHkgc2VjdXJlZCBzZXJ2aWNlDQo+ID4gZGlzY292ZXJ5IHRlY2huaXF1ZXMgKGUuZy4g aVNOUywgU2VjdGlvbiA0LjIuNykgdG8gZW5zdXJlIHRoYXQgaXQgaXMNCj4gPiB0YWxraW5nIHRv IHRoZSBpbnRlbmRlZCB0YXJnZXQgcHJpbmNpcGFsLg0KPiANCj4gU29tZSB0ZXh0IHNvbWV3aGVy ZSBzaG91bGQgbm90ZSB0aGF0IEtlcmJlcm9zIGlzIG5vdCB1c2VkIHRvIHByb3ZpZGUNCj4gaW50 ZWdyaXR5IG5vciBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiB0byB0aGUgaVNDU0kgcHJvdG9j b2wgKGFuZA0KPiB0aGF0IG9ubHkgSVBzZWMgZG9lcywgYW5kIHNvIG9uKS4NCg0KU3VyZSwgZ29v ZCBzdWdnZXN0aW9uLCB3ZSdsbCBhZGQgYSBzZW50ZW5jZSB0byB0aGF0IGVmZmVjdC4NCg0KPiAN Cj4gTmljbw0KPiAtLQ0KDQo= From nico@cryptonector.com Wed May 29 13:18:00 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2D021F8ED8; Wed, 29 May 2013 13:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcHpjbwq-BrO; Wed, 29 May 2013 13:17:53 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9759B21F8E76; Wed, 29 May 2013 13:17:53 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id A0DBF2AC0A9; Wed, 29 May 2013 13:17:51 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id D765C2AC0DB; Wed, 29 May 2013 13:16:22 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so3927927wib.6 for ; Wed, 29 May 2013 13:15:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cH9Qd6mPXz5OIJvcUd+7TbHIE7iSSQKXFt8y1l+B1rU=; b=KvMMqLoi039XlY3zwkUoU11sbHV+W3OLlPXvhUNoMzCLPELABE9cY/j5MiBjqxx4DF uFidGQMtGVCZvK2m+Pg/Qmk/pTLY7U3067SweY+K8EUvfCNDQEvWz79lR5zs0YeYxN6M 9sPeCwswJygv1LjE1CQK5iJf80o9QRHxmlDpeGLVc+yYq9pgA1a3drKrrXzQUdT2Xu4g 9WJeWQJSECjJGKUmzttODmZer5fgwdUSY7Eq3/StYMRFh6w4vzOc0EE6SUYrb9xeGbfG NMxq4ijaShABg4Gy6zDa4xcfu69M5vvIyrEhRSJFqzwbfp5ly6hZ3dd+6X/hl8f3cZNg 5iRA== MIME-Version: 1.0 X-Received: by 10.194.83.5 with SMTP id m5mr2283589wjy.20.1369858532730; Wed, 29 May 2013 13:15:32 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Wed, 29 May 2013 13:15:32 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com> Date: Wed, 29 May 2013 15:15:32 -0500 Message-ID: From: Nico Williams To: "Black, David" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 30 May 2013 08:02:01 -0700 Cc: "kitten@ietf.org" , "storm@ietf.org" Subject: Re: [storm] [kitten] Kerberos Considerations for iSCSI Authentication X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:18:00 -0000 On Wed, May 29, 2013 at 9:43 AM, Black, David wrote: > I do want to head off one area of comments - please send any "you > should use GSS-API" comments to /dev/null. iSCSI was specified to use > Kerberos w/o GSS-API a long time ago, so GSS-API for iSCSI would be a > new iSCSI authentication mechanism that should be in a separate draft, > as opposed to this update (which is already long enough). Other comments to head of: - Kebreros <-> IPsec binding? never mind; we failed to get uptake on RFC5660. > ------------------ > > 9.2.3 Kerberos Considerations for iSCSI Authentication > > iSCSI uses Kerberos via "bare" tokens - i.e. does not use GSS-API ([RFC4121]) - > for authenticating the two Kerberos principals during the iSCSI Login process. s/tokens/PDUs/ (and define the term: Protocol Data Unit). Or better: NEW: iSCSI uses raw Kerberos V5 [RFC4120] for authenticating a client (iSCSI initiator) principal to a service (iSCSI target) principal. Note that iSCSI does not use the Generic Security Services Application Programming Interface (GSS-API) [RFC2743] nor the Kerberos V5 GSS-API security mechanism [RFC4121]. > This implies that iSCSI implementations supporting the KRB5 AuthMethod > (Section 12.1) are directly involved in the Kerberos protocol. Specifically, > the following actions MUST be performed as specified in [RFC4120]: The first sentence of the above para says nothing to me :( Remove it? > - Target MUST validate the KRB_AP_REQ to ensure that the > initiator can be trusted > - When mutual authentication is selected, the initiator > MUST validate KRB_AP_REP > to determine the outcome of mutual authentication Yes. (Assuming there's text elsewhere saying that these PDUs have to be sent and received in order to validate them :) > As Kerberos V5 is capable of providing mutual authentication, implementations > SHOULD support mutual authentication by default for login authentication. Is there a reason not to make this a MUST? > Note however that Kerberos authentication only assures that the server > (iSCSI target) can be trusted by the Kerberos client (initiator) and > vice-versa; an initiator should employ appropriately secured service > discovery techniques (e.g. iSNS, Section 4.2.7) to ensure that it is > talking to the intended target principal. Some text somewhere should note that Kerberos is not used to provide integrity nor confidentiality protection to the iSCSI protocol (and that only IPsec does, and so on). Nico --