|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] DRAFT Minneapolis minutes
Comments on the list please, and I apologize in advance for the
inevitable line wraps that will be "helpfully" inserted by the
mailers. The final version of these will go to the secretariat
around the middle of next week. Thanks, --David
IETF 53
IPS Working Group Meeting DRAFT Minutes
*** Thanks to Pat Thaler, Mark Bakke and Ed Gardner for taking notes ***
--------------------------- Monday, March 18, 2002
-- Administrativa (David Black)
iSCSI Requirements Draft
IESG requested few changes
Must Implement Confidentiality
Accommodate future use of SCTP w/ minimal iSCSI
changes
Several Editorial Tweaks
Revised Draft in Allison's hands. To be submitted for
IESG Last Call shortly.
New milestones update to charter page by end of next week.
Draft authors MUST read and heed
www.rfc-editor.org/policy.org
www.ietf.org/ID-nits.html
WG Last Calls
FC Encaps, FCIP and iFCP: CLOSED
Next up: Security and iSCSI.
Others by Yokohoma, including some MIBs.
String Prep - IDN last call soon -
Major editorial changes expected in near future.
Split content between stringprep and stringprep profile.
Need to hold back iSCSI StringPrep draft.
Should be clear by Yokohoma.
Q: How to go to last call on iSCSI?
A: Can go to last call even with normative references, but will be held up
at
RFC editor. So, iSCSI can go to last call; will get held up only if
iSCSI StringPrep is not ready - most likely will not cause holdup.
Note: Conflict between IETF-54 and T10 in July, may need an interim for
iSCSI issues.
Request: IEEE meets week before IETF-54; request that IPS meet in latter
half
of IETF week.
IPS WG how many to Yokohoma?
~15 will attend; approx same would not attend; many do not know yet.
Web Site: Since the CMU Web Site is no longer available for IPS.
Several volunteers to host web site received
WG thanks those who volunteered, but chairs request a vendor neutral site -
preferably an .edu site.
Roger Cummings has volunteered to host IPS site on T11 web site.
To confirm with Kumar Malavalli, who supports financially.
-- Security Update: (David Black)
New Security AD: Steve Bellovin
Discussion with Steve on IPS and security issues --
IPsec Encapsulation: Tunnel MUST, Transport MAY OK
Can remove "MUST implement transport when RFC 2401 says so" language.
Warning: correct IPsec SPD configuration is particularly important for
tunnel mode because the default action is to forward the packet
to the inner IP address.
AES CTR Mode will be OK; provided that the IPsec WG draft specifying this
gets sufficient review.
Reuse of same <key, IV> pair yields catastrophic
failure
Details on preventing this must be 100% correct and
clear.
IPsec notation: For the IPS working group, we will adopt the IPsec
convention,
as opposed to IPSec.
Add a requirement to the draft that ESP confidentiality MUST NOT be used in
the
absence of ESP Authentication (cryptographic integrity) because
without
integrity a third party can make changes to the encrypted data to
make
change to the plain text, especially in counter mode.
-- Security Outstanding Issues: (Bernard Aboba)
AES-CBC: All IPsec transforms are stateless.
SA per TCP connection
Draft 09 had specified a single IPsec Phase 2 SA per TCP connection
This had no security value, and was hard to implement.
May be situations where separate SAs my be useful.
Proposed Resolution: Remove all normative language relating to
SA per TCP connection from the draft; (-11)
Put in text explaining when a separate IPsec SA might be useful.
(To list)
Configurable Parameters
Clear summary of the requirements for ALL configurable IPsec
parameters should be provide. Will be done in 12.
Identification Payloads - Need to clearly differentiate between Phase 1 and
Phase 2 payloads.
Q: Currently have IP subnet & IP Address Range as SHOULD NOT. Is this
what we want, for gateway scenarios?
Rationale - end to end, these are requirements for the IPsec SAs
that are
directly carrying storage traffic.
This document is not supposed to impose requirements on connections
between
a storage device and gateways.
Will ensure SHOULD NOT in draft (as opposed to MUST NOT), to allow
for
implementations that can't distinguish these.
Vendor solution can have IPsec implementations which support both
IPS
apps and non IPS apps.
May in fact have nested IPsec implementations - e.g. VPN with iSCSI
traffic.
Directive to group: Check what will be used in solutions, is this going to
be a problem?
If so, then need to bring to list ASAP.
Main vs Aggressive Mode: FCIP currently at MAY for aggressive mode;
needs to change to either SHOULD or MUST for aggressive mode.
Question on FCIP being excluded from requiring Aggressive mode at HB
interim. NOTE: A check of the minutes reveals no such
exclusion -
this may have been confused with the ID_USER_FQDN
discussion.
Mandating in specification that FCIP not use DHCP will not fly with the
IESG.
Essentially, do not know how peer obtained IP address, and the
security
problem caused by the DHCP assigned address affects the peer, not
the
unit using DHCP.
Note: Many IPsec implementations today do not use aggressive mode.
Conclusion: Will make Aggressive mode a SHOULD with suitable warnings about
dynamic assignment of IP addresses and Main mode.
SLPv2 Security - In progress. Mark will Bakke work on something similar to
iSNS storage of IPsec "policy" for SLPv2.
iSNS security Policy -- At issue, how to distribute security policy
securely.
Required Dependencies: Currently SRP is a MUST implement. This, due to the
IP issues, is currently the biggest outstanding issue wrt
dependencies.
Bernard will make presentation available on his web site. (drizzle)
-- FC Frame Encapsulation (Ralph Weber)
WG Last Call closed on this document at 8am Monday, March 18.
75 last call comments. Editorial + Technical.
Technical amounts to about 1/3 or ½ of the comments.
Mostly minor issues.
Proposal (David): Record whether the CRC bit is checked in the
Protocol Number (e.g. w/ IANA)
Due to fact that protocols CRC is either valid for protocol or not.
Elizabeth disagrees, per resolution at Nashua interim.
David and Ralph will compose proposed text.
SOF/EOF codes - add text to draft as to where values come from.
Will not be assigned by IANA. T11 is responsible for defining.
This will be made clear in new text.
Add applicable class codes column to table in FC Encaps.
FC Encaps will be normative source of these codes;
other specs can draw from these, if they so wish.
SNTP sections will need to be drawn into the draft;
SNTP is informational, so can not have normative references to it.
~10% changes in text. Likely will not need second last call.
-- FCIP (Ralph Weber)
WG Last Call closed on this document at 8am Monday, March 18.
Has more and more substantial technical comments, but have not been
reviewed
thoroughly as of yet.
Will likely need to go through WG last call again.
Need to analyze Annex C - do there exist algorithms that can fool the FCIP
resync.
Algorithm needs to be 100%; disagreement on whether current algorithm is
100%.
-- SLP for FCIP (David Petersen)
Ready for last call. There are implementations of this.
-- FCIP MIB (Anil Rijhsinghani)
Currently still at 01; corresponds to current FCIP draft.
Plan: Incorporate comments from Keith; align with BB-2.
-- iFCP (Charles Monia)
WG Last Call closed on this document at 8am Monday, March 18.
Need to digest comments received.
Plan: Generate response to technical comments by March 22;
Target for closure by March 29.
Produce -11 by April 19.
2nd WG last call for iFCP likely.
-- iFCP MIB (Josh Tseng)
No change in status.
Keith McCloghrie (MIB Technical Advisor) may not have made
comments on this document yet...
-- iSNS (Josh Tseng)
Proposal for DHC Option number for iSNS; to be discussed on Wed at DHC WG.
Added Auth Method attrib to configure/discover iSCSI authentication
methods using iSNS
Considering whether to add attributes to configure Kerberos
iSCSI-FC mapping: EUI64 Token to be renamed to WWN Token, since not a
direct mapping.
-- iSNS MIB (Josh Tseng)
Migrated to new FCMgmt MIB
Incorporating Keith's comments
Incorporating updates from iSNS draft
New authorization MIB developed - more of an identity/authentication MIB.
No overlap with iSNS /iSNS MIB and new MIB.
-- FC Mgmt MIB (Keith McCloghrie)
Work originated in ipfc wg
Will obsolete draft-ietf-ipfc-fcmgmt-int-07 & RFC 2837.
At Interim, agreed to:
Add support for Class F
Ref FC-MI for status of class 1
Discussed Counter32 & Counter64 support. -
NM-AD indicates that counter-size is WG
decision.
Based on interim meeting input, counter32
will be
supported.
Q: Why support SNMPv1, with all security work going on?
A: Security is must implement, not must use.
Also, Fibre Channel specific, where SNMPv1 support common
& security requirements differ.
Deferred to other MIBs
FC Name Server (of most import)
Class 4
Zone Server
Security
HBA API MIB
Will be ready for last call shortly.
-- Request publication of Sheinwald CRC draft as Informational RFC
This is information on analysis of CRCs and was used in determination to
use CRC-32C for iSCSI
No objections. WG chairs will recommend that draft will be published as
informational.
-- iSCSI Plugfest (David Black presenting for Yamini Shastry)
19 companies attended.
Draft 8 & 9 supported.
Issues are now moving to secondary functionality instead of primary.
Some required features still only supported by no or few implementations.
iSCSI supports iSCSI-3! If using SCSI-1 or SCSI-2, need to handle on your
own.
Next interop June 3-7, UNH.
Request testing against only one draft - contact Stephen Schaeffer.
------------------- End of Monday Meeting, Total Attendees: 77
--------------------Tuesday, March 19, 2002
-- Transport Mode Requirements (David Black)
Currently in security text as MUST implement when RFC 2401 requires it.
Consensus Call - Should this remain MUST, or go to MAY implement
in all cases?
~8 to leave as is.
~20 to change to MAY
Rough Concensus: Change transport mode to MAY.
Further discussion on list.
-- SRP Intellectual Property Rights (David Black)
Note: The following is status. Does not constitute legal advice
of any nature.
Three organizations may have patent claims against SRP:
Stanford, Phoenix Technologies & Lucent Technologies
-- Phoenix Technologies position on SRP (David Jablon)
Draft-jablonj-speke-00.txt provides background.
Covers SRP-4, which is in the same family of SRP-3.
Compatible with IEEE 1363 & X9
Addresses IPS WG IP questions.
Patent Letter presented - Phoenix has PN 6,226,383, may be applicable to
2945.
Phoenix will provide non-exclusive licensing at reasonable,
non-discriminatory terms.
Contact: Katherine_Stolz@phoenix.com
(Copy of patent letter at end of these minutes.)
-- Lucent position (David Black)
Has not changed since the interim meeting.
(The following is based on oral discussion with Lucent IP division)
In summary, Lucent will not do the research to determine if the EKE
patents apply to SRP, and will not take a position on whether or
not it applies.
Lucent feels that it is up to the SRP implementer to undertake the research.
Lucent will license the EKE patents under normal Lucent licensing practices.
This is not necessarily "reasonable and non discriminatory terms and
conditions".
Need to determine if we want to keep SRP as a must implement in the iSCSI
specification.
A lengthy discussion ensued, some highlights/excerpts follow:
Many large companies, IBM included, have license exchanges with Lucent.
These companies may be willing to license the software they have developed.
May be able to use these cross-licensing practices to get around Lucent.
Response: Need to take care and check closely with lawyers, to see if this
is even
possible - if cross licensing agreements will allow the licensing
of
technology to the third company.
Comment that anything with such a patent statement (Lucent's last statement)
to not be a good idea to do a MUST or SHOULD.
Comment that IPR risks and risks of unknown licensing terms could deter
implementation,
particularly by smaller companies without large legal departments.
Scott Bradner clarified that IETF procedures do not require IPR free
technology.
He indicated that there's no solid way to determine whether there is
a claim
(or not a claim) without going to court.
He further warned that abandoning a useful or essential technology due to
threatened
IPR was a denial of service attack opportunity for claimants that might want
to delay
or subvert the standards process.
Rule of approach: If it's the right technology to use, and nothing else
right
enough to replace, should use it. If there's another way to get close
enough,
use that. But don't rule out because of perceived IPR issues.
Discussion between David Black and Steve Bellovin: CHAP itself would be
considered acceptable, but Steve would prefer it be wrapped with
unauthenticated Diffie-Hellman exchange. Prevents passive
dictionary
attack; still susceptible to active dictionary attack.
Uri Blumenthal indicated other options available to make CHAP more robust.
Q: Does the current group want to change the MUST requirement for SRP?
Consensus call: SRP is currently Mandatory to Implement.
Roughly 50/50 want to reconsider it, no rough consensus.
Must reconsider.
Not enough discussion to make this decision in this meeting.
Could use security group as basis, and add a few people, including Uri and
Perry.
Suggestion on making CHAP MUST and SRP SHOULD, to address IP concerns.
If IP concerns reason for SHOULD, then SHOULD is too strong - by 2119,
SHOULD is implement unless strong reason not to - complexity/IP licensing
issues are not a sufficient reason.
Issues to be addressed by enhanced Security Design Team, with proposals for
resolution in (hopefully) short order.
NOTE: Subsequent to the meeting, Lucent committed to "reasonable and
non-discriminatory terms" for "any Lucent patents determined
to be essential to the implementation of SRP as an IETF standards
track specification".
-- SCSI MIB (Yaron Lederman)
Have feedback from T10 CAP and SNIA; have stable object model
- No response from IPS list so far
- Assume we can go forward
- Working on editorial and boilerplate changes
Should object population text become a WG Information Draft?
- Planning to publish as an individual draft.
- How much effort should we invest?
SCSI MIB folks believe this is useful and helpful,
Keith feels text is too big to include in MIB itself.
Consensus call: Any objections to informational draft?
No objections. Draft will be submitted as WG document, informational RFC
Pending Issues
- Request for a fixed-size error log
- No real requirement from vendors
- Will not do this in SCSI MIB
(no objections)
- SNMPv1 support - high-capacity counters.
Provide one low-order 32-bit counter for each 64-bit counter.
- Do we need the high-order 32?
David Black: how fast will they wrap?
Yaron: read/write will wrap relatively quickly.
Q: Are high order counters used in other drafts?
Keith McCloghrie: ifMIB does not have high-order 32s. RMON has both low
and high 32s. Read/writes are in blocks; these don't increment
as fast as byte counters. Could do megabyte counters instead.
Can do without the high-order counters.
David Black: Should anticipate 10 to 40 Gbit rates.
Elizabeth Rodriguez: Any objections to megabyte counters?
(None)
Yaron suggested an FCP MIB might be useful -
Question as to where FCP MIB belongs - T11 or T10. (T10)
Is InitiatorDeviceStatus required?
- Should it be admin or operating status?
(design team should use best judgment)
Yaron described MIB family model
David Black: Encourage implementers to look at these now;
Mgmt vendors will be knocking.
Anticipated Last Call before Yokohoma (April/May timeframe)
-- iSCSI MIB, Auth MIB (Mark Bakke)
FC Family address allocation numbers received from IANA.
- Mark to send IANA AF response to list.
Mark to send the SLP MIB link to list. (Work in progress in another WG)
-- iSCSI Naming and Discovery (Mark Bakke)
Some normative text is currently present in the N&D document.
N&D is informational, so cannot have iSCSI dependency on this
draft.
Normative text will be moved to the iSCSI draft.
-- iSCSI Boot (John Hufferd)
Informational draft. Normative text will be removed.
-- iSCSI Main Draft (Julian Satran)
Major issues closed
Current text has SHOULD have F=1 on last. To be changed to
MUST.
Request for 2 Max Burst Size - Anyone present interested -
Concensus: only 1 Max Burst Size.
Data Fulfillment/R2T issues discussed - To list.
NOTE: Subsequent closure of this issue was that an
Initiator
MUST provide all the data requested in an
R2T -
failure to do so is a protocol error
-- iSCSI issues (Dave Peterson)
No guidance for suitable timers, counters and ULP timeout values.
(ULP timeout guidance may be device dependent (e.g. disk vs tape)
- Text to be added to draft.
Dave to post text describing CRN (Command Reference Number) processing and
behavior.
Issues corresponding to gateway to device interaction also brought up, e.g.
termination of MODE page at gateway or pass thru.
- To be discussed by bridge & gateway design team.
iSCSI Mock WG Last Call Planned:
Plan is to issue iSCSI-12 draft within a few days and perform a mock
WG
last call, to move forward pending resolution of authentication
protocol issue.
------------------- Meeting concluded.
-- Phoenix Technologies Patent Letter re SRP
From http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt
Received: March 6, 2002
From: David Jablon <dpj@world.std.com>
via David Black <black_david@emc.com>
To: Internet Engineering Task Force
Date: March 18, 2002
This is to advise the IETF that Phoenix Technologies Ltd.
("Phoenix") has U.S. Patent Number 6,226,383 that may
relate to the IETF document RFC 2945 titled "The SRP
Authentication and Key Exchange System".
To the extent that this patent assigned to Phoenix is
necessary for implementation of RFC 2945 or any related
IETF standard, Phoenix will provide, upon written request,
to implementers of the relevant standard, a non-exclusive
license under reasonable and non-discriminatory terms.
Phoenix has licensed this technology to companies, and
accepts inquiries regarding licensing or evaluating the
SPEKE technology. For these inquiries, please contact our
security products department at:
Katherine_Stolz@phoenix.com
Vice President, Security Products
Phoenix Technologies
Any questions or issues regarding this communication should
be directed to the Phoenix Technologies Legal Department.
Scott_Taylor@phoenix.com
Associate General Counsel
Phoenix Technologies Ltd
411 E. Plumeria Drive
San Jose, CA 95134
=======================================================
Received February 12, 2002
From: David Jablon <dpj@world.std.com>
via David Black <black_david@emc.com>
To: IETF IP Storage Working Group
Subject: Phoenix Patents and RFC 2945
February 6, 2002
Dear working group members,
Regarding the inquiry by working group co-chair David Black into the nature
of U.S. patent 6,226,383 and its relation to SRP and RFC 2945, this letter
presents a status update on Phoenix's plans to provide an appropriate
response for the working group. This letter also presents a general summary
of our licensing practices and products in the field of password-based
cryptography, which I hope will assist you in the planning process.
Phoenix owns patent 6,226,383 which describes the SPEKE methods for
zero-knowledge password authentication. An investigation into exactly how
this patent relates to RFC 2945 is now underway within the company. While
providing guarantees and assurances for use of technology developed by other
organizations has not been a traditional priority for Phoenix, there is now
recognition of the need for this working group and others to have clarity in
this matter, and a position statement will be provided very soon.
Phoenix Technologies, in part through the acquisition of Integrity Sciences,
has developed the SPEKE family of zero-knowledge password methods, providing
both licenses and implementations. These protocols have been cited and
studied in numerous research papers over the past several years. In
particular, the BSPEKE protocol can provide a plug-and-play upgrade for SRP.
An Internet Draft discussing these issues is also being prepared. These
methods are comparable to the best of any similar methods, and they are
easily shown to be unencumbered by the other patents in this field.
It would seem a shame for a new standards effort to avoid zero-knowledge
password techniques as a purely cost-savings measure, given the choices
available. The need for convenient, strong, and inexpensive security
built-in to the infrastructure of Internet applications is as great today as
ever. The SPEKE techniques represent a generational improvement in personal
authentication, providing strong security with minimal effort. These
methods provide the best choices in this field, with the cleanest
implementations, optimal security, best alignment with standards, and
easiest license agreements for commercial deployment of zero-knowledge
password techniques.
A statement regarding licensing of the SPEKE patent in the context of the
IEEE 1363 standard is on file with the IEEE, and Phoenix is also committed
to providing an updated statement in this same time frame that conforms to
both IEEE and IETF policies assuring reasonable and non-discriminatory
terms. But more importantly, as a leading provider to the PC industry,
Phoenix will stand behind its technology. Phoenix has a 20-year history of
broadly licensing products to this industry, and has helped to pioneer many
widely used standards and technologies that are built-in to the systems that
we all take for granted. Our history of cooperation with many of the
leading companies in the industry makes Phoenix naturally suited to gently
encouraging the adoption of this new class of strong and convenient security
techniques.
Sincerely,
David Jablon
CTO, Phoenix Technologies
508.898.9024 direct
david_jablon@phoenix.com
Phoenix Technologies Ltd.
320 Norwood Park South
Norwood, MA 02062
781.551.5000 main
www.phoenix.com
Home Last updated: Wed Apr 03 22:18:22 2002 9476 messages in chronological order |