WG Review: EAP Method Update (emu)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by December 28. +++ EAP Method Update (emu) Current Status: Proposed Working Group Chairs: TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing List: TBD Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of this methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - Enhanced functionality to enable a TLS-based EAP method to support authentication methods beyond certificates, channel bindings and other optional functions required in RFC 4017. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. Depending on an analysis of the behavior of existing implementations, it is possible that this effort may be able to use the existing EAP-TLS type code, or it may need to be handled via assignment of a new EAP Type Code. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. In order to facilitate the development of the shared secret and password based methods design teams will be formed. The design teams should take into consideration existing methods including mechanisms based on EAP-TLS such as TLS-PSK. Feb 2006 Form design team to work on strong shared secret mechanism Mar 2006 Submit 2716bis I-D Jun 2006 Submit first draft of enhanced EAP-TLS I-D Jul 2006 Form password based mechanism design team Jul 2006 Submit first draft of shared secret mechanism I-D Aug 2006 Submit 2716bis draft to IESG for Proposed Standard Nov 2006 Submit 2716bis draft to IESG for draft standard Dec 2006 Submit first draft password based method I-D Jan 2007 Submit Strong Shared Secret Mechanism to IESG Jan 2007 Submit enhanced EAP-TLS to IESG Aug 2007 Submit password Based Mechanism to IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Pseudo Wire Emulation Edge to Edge (pwe3)
A modified charter has been submitted for the Pseudo Wire Emulation Edge to Edge (pwe3) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by December 28th. +++ Pseudo Wire Emulation Edge to Edge (pwe3) = Current Status: Active Working Group Chair(s): Stewart Bryant [EMAIL PROTECTED] Danny McPherson [EMAIL PROTECTED] Internet Area Director(s): Mark Townsley [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Mark Townsley [EMAIL PROTECTED] Secretary(ies): Matthew Bocci [EMAIL PROTECTED] Mailing Lists: General Discussion: pwe3@ietf.org To Subscribe: [EMAIL PROTECTED] In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs. A pseudowire emulates a point-to-point link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates edge to edge and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. WG Objectives: Specify the following PW types: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH and Fibre Channel. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Further enhance PW specifications to enable more transparent emulation when necessary, for example the retention of FCS across a PW. Define a mechanism for MPLS PWs that
WG Action: RECHARTER: Extended Incident Handling (inch)
The charter of the Extended Incident Handling (inch) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Extended Incident Handling (inch) == Current Status: Active Working Group Chair(s): Roman Danyliw [EMAIL PROTECTED] Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing Lists: General Discussion: inch@nic.surfnet.nl To Subscribe: [EMAIL PROTECTED] In Body: subscribe inch Archive: http://listserv.surfnet.nl/archives/inch.html Description of Working Group: Background Computer security incidents occur across administrative domains often spanning different organizations and national borders. Therefore, the free exchange of incident information and statistics among involved parties and the responsible Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. Scope The purpose of the Incident Handling (INCH) working group is to define a data format for exchanging security incident information used by a CSIRT. A CSIRT is defined broadly as an entity with a security role or responsibility in a given organization. Often there is a communication and collaborating component. Organizationally, a CSIRT might be a dedicated team in a network operations group, or a single individual with other responsibilities. The primary use case for the INCH work is to standardize the the communication between a CSIRT and: * its constituency (e.g., users, customers) reporting misuse; * parties involved in an incident (e.g., law enforcement, attacking site); or * peer CSIRTs sharing information. In doing such sharing, especially when action is being requested, due attention must be paid to authorization and privacy issues. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution. Specifically, the working group will address the issues related to representing * the source(s) and target(s) of system misuse, as well as the analysis of their behavior; * the evidence to support any analysis results; * a scheme to document the incident investigation and analysis process; and * constructs to facilitate the exchange of security information across administrative domains (e.g., internationalization, data sensitivity). The WG will investigate the information model needed to support the typical, operational workflow of the incident handling processes found at Internet Service Providers; Managed Security Service Providers; Risk Analysis vendors; and traditional, internal CSIRTs. Constraints The WG will not attempt to - - define an incident or address the implications of sharing incident data across administrative domains; - - define a format for computer security related information for which there is already a standard, but where applicable, provide full compatibility (e.g. IDWG's IDMEF, Mitre's CVE); or - - define a protocol for exchanging the incident information. Output of Working Group 1. A document describing the high-level functional requirements of a data format for collaboration between CSIRTs and parties involved when handling computer security incidents. 2. A specification of the extensible, incident data language that describes the data formats that satisfy the requirements. 3. Guidelines for implementing the WG data format (Output #2 of the WG). 4. A set of sample incident reports and their associate representation in the incident data language. Goals and Milestones: DoneInitial I-D of the incident data language specification DoneInitial I-D for the requirements specification DoneInitial I-D of the implementation guidelines document DoneInitial I-D of the traceback extension specification DoneSubmit initial draft of phishing extension specification I-D Nov 2005Initial I-D of a transport binding specification Dec 2005Submit messaging format specification I-D to the IESG as Proposed Dec 2005Submit incident data language specification I-D to the IESG as Proposed Dec 2005Submit requirements I-D to the IESG as Informational Dec 2005Submit transport binding specification I-D to the IESG as Proposed Dec 2005Submit phishing extension specification I-D to the IESG as Proposed Feb 2006Submit implementation guidelines I-D to the IESG as Informational ___ IETF-Announce mailing list
RFC 4228 on Requirements for an IETF Draft Submission Toolset
A new Request for Comments is now available in online RFC libraries. RFC 4228 Title: Requirements for an IETF Draft Submission Toolset Author(s): A. Rousskov Status: Informational Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 31 Characters: 76952 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-tools-draft-submission-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4228.txt This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4228.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4324 on Calendar Access Protocol (CAP)
A new Request for Comments is now available in online RFC libraries. RFC 4324 Title: Calendar Access Protocol (CAP) Author(s): D. Royer, G. Babics, S. Mansour Status: Experimental Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 131 Characters: 254638 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-royer-calsch-cap-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4324.txt The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4324.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4315 on Internet Message Access Protocol (IMAP) - UIDPLUS extension
A new Request for Comments is now available in online RFC libraries. RFC 4315 Title: Internet Message Access Protocol (IMAP) - UIDPLUS extension Author(s): M. Crispin Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 8 Characters: 16629 Obsoletes: 2359 I-D Tag:draft-crispin-imap-rfc2359bis-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4315.txt The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4315.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4298 on RTP Payload Format for BroadVoice Speech Codecs
A new Request for Comments is now available in online RFC libraries. RFC 4298 Title: RTP Payload Format for BroadVoice Speech Codecs Author(s): J.-H. Chen, W. Lee, J. Thyssen Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 30099 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-avt-rtp-bv-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4298.txt This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4298.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4230 on RSVP Security Properties
A new Request for Comments is now available in online RFC libraries. RFC 4230 Title: RSVP Security Properties Author(s): H. Tschofenig, R. Graveman Status: Informational Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 48 Characters: 121030 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-nsis-rsvp-sec-properties-06.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4230.txt This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This document is a product of the Next Steps in Signaling Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4230.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Network Configuration (netconf)
The charter of the Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Network Configuration (netconf) Current Status: Active Working Group Chair(s): Simon Leinen [EMAIL PROTECTED] Andy Bierman [EMAIL PROTECTED] Operations and Management Area Director(s): Bert Wijnen [EMAIL PROTECTED] David Kessens [EMAIL PROTECTED] Operations and Management Area Advisor: Bert Wijnen [EMAIL PROTECTED] Technical Advisor(s): Wesley Hardaker [EMAIL PROTECTED] Mailing Lists: General Discussion: netconf@ops.ietf.org To Subscribe: [EMAIL PROTECTED] In Body: in msg body: subscribe Archive: https://ops.ietf.org/lists/netconf Description of Working Group: Wes Hardaker is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanims or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures. The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s). The initial work will be restricted to the following items: - Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. - Netconf over Transport-TBD Specification, which defines how the Netconf protocol is used with the transport protocol selected by the group, and how it meets the security and transport layer requirements of the Netconf Protocol Specification.. There will be a document of this type for each selected transport protocol. The working group will take the XMLCONF Configuration Protocol draft-enns-xmlconf-spec-00.txt as a starting point. Goals and Milestones: DoneWorking Group formed DoneSubmit initial Netconf Protocol draft DoneSubmit initial Netconf over (transport-TBD) draft DoneBegin Working Group Last Call for the Netconf Protocol draft DoneBegin Working Group Last Call for the Netconf over (transport-TBD) draft DoneSubmit final version of the Netconf Protocol draft to the IESG DoneSubmit final version of the Netconf over SOAP draft to the IESG DoneSubmit final version of the Netconf over BEEP draft to the IESG DoneSubmit final version of the Netconf over SSH draft to the IESG Dec 2005Update charter Jan 2006Submit first version of NETCONF Notifications document Sep 2006Begin WGLC of NETCONF Notifications document
UPDATED: WG Action: RECHARTER: Extended Incident Handling (inch)
The charter of the Extended Incident Handling (inch) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Extended Incident Handling (inch) == Current Status: Active Working Group Chair(s): Roman Danyliw [EMAIL PROTECTED] Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing Lists: General Discussion: inch@nic.surfnet.nl To Subscribe: [EMAIL PROTECTED] In Body: subscribe inch Archive: http://listserv.surfnet.nl/archives/inch.html Description of Working Group: Background == Computer security incidents occur across administrative domains often spanning different organizations and national borders. Therefore, the exchange of incident information and statistics among involved parties and associated Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. Scope = The purpose of the Incident Handling (INCH) working group is to define a data format for exchanging security incident information used by a CSIRT. A CSIRT is defined broadly as an entity (either a team or individual) with a security role or responsibility for a given constituency (e.g., organization, network). The use case for the INCH WG output is to standardize the information model and messaging format currently used in communication between a CSIRT and the: * constituency (e.g., users, customers) from which it receives reports of misuse; * other parties involved in an incident (e.g., technical contact at an attacking site, other CSIRTs); and * analysis centers performing trending across broad data-sets. These INCH developed formats will replace the now largely human- intensive communication processes common in incident handling. The working group will address the issues related to representing and transporting: * the source(s) and target(s) of system misuse, as well as the analysis of their behavior; * the evidence to support this analysis; * status of an incident investigation and analysis process; and * meta-information relevant to sharing sensitive information across administrative domains (e.g., internationalization, authorization, privacy). Constraints === The WG will not attempt to define - - an incident taxonomy; - - an archive format for incident information; - - a format for workflow process internal to a CSIRT; or - - a format for computer security related information for which there is already a working standard. Output of Working Group === 1. A set of high-level requirements for a data format to represent information commonly exchanged by CSIRTs. 2. A specification of an extensible, incident data description language that describes a format that satisfies these requirements (Output #1). 3. A set of sample incident reports and their associate representation in the incident data language. 4. A message format specification and associated transport binding to carry the encoded description of an incident (Output #2). 5. Guidelines for implementing the data format (Output #2) and associated communications (Output #4) Goals and Milestones: DoneInitial I-D of the incident data language specification DoneInitial I-D for the requirements specification DoneInitial I-D of the implementation guidelines document DoneInitial I-D of the traceback extension specification DoneSubmit initial draft of phishing extension specification I-D Nov 2005Initial I-D of a transport binding specification Dec 2005Submit messaging format specification I-D to the IESG as Proposed Dec 2005Submit incident data language specification I-D to the IESG as Proposed Dec 2005Submit requirements I-D to the IESG as Informational Dec 2005Submit transport binding specification I-D to the IESG as Proposed Dec 2005Submit phishing extension specification I-D to the IESG as Proposed Feb 2006Submit implementation guidelines I-D to the IESG as Informational ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
UPDATED: WG Action: RECHARTER: Mobility for IPv4 (mip4)
The Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Mobility for IPv4 (mip4) == Current Status: Active Working Group Chair(s): Peter McCann [EMAIL PROTECTED] Henrik Levkowetz [EMAIL PROTECTED] Internet Area Director(s): Mark Townsley [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Margaret Wasserman [EMAIL PROTECTED] Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: [EMAIL PROTECTED] In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its permanent home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 pretty clearly shows that full 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and radext, the workgroup will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the Radius Extensions WG, adjust, and submit this for publication. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. Goals and Milestones: DoneAAA Keys for MIPv4 to
Last Call: 'Repeated Authentication in IKEv2' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Repeated Authentication in IKEv2 ' draft-nir-ikev2-auth-lt-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS)' to Proposed Standard
The IESG has received a request from the S/MIME Mail Security WG to consider the following document: - 'Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS) ' draft-ietf-smime-gost-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
