December 2013
doc.: IEEE NNN
IEEE 802 Response to FDIS comments on
IEEE 802.1AE and IEEE 802.1X
16 December 2013
Authors:
Name
Submission to SC6
Company
Phone
Slide 1
email
December 2013
doc.: IEEE NNN
This presentation provides responses to comments
on IEEE 802.1X & IEEE 802.1AE during FDIS ballots
• The FDIS voting results on IEEE 802.1X are in N15771
– It passed 16/1/12 (China NB negative)
– Comments were received from China NB and Switzerland NB
• The FDIS voting results on IEEE 802.1AE in N15770
– It passed 16/1/13 (China NB negative)
– Comments were received from China NB and Switzerland NB
• The FDIS comments have been processed in a timely manner using the
mechanisms defined and agreed in N15606
• This presentation provides the proposed responses from IEEE 802 to all
comments by China NB and the Switzerland NB in the FDIS ballots
Submission to SC6
Slide 2
December 2013
doc.: IEEE NNN
China NB comment CN.1 on IEEE 802.1X
China NB comment CN.1 on IEEE 802.1X:
• Since the procedural and technical concerns China NB proposed in 6N15555 still
haven’t reasonably disposed in this FDIS text, and referencing issues mentioned
below exist in this text, so China NB has to vote against on this FDIS ballot. If
these issues could not be disposed reasonably and this proposal passes the FDIS
ballot, it is regretful for China to be obliged to lose the responsibility and obligation
of complying with and adopting the standard. Furthermore, China NB wishes to
state for the record
Submission to SC6
Slide 3
December 2013
doc.: IEEE NNN
China NB comment CN.1 on IEEE 802.1X (cont)
IEEE 802 response to comment CN.1 on IEEE 802.1X
• IEEE 802 thanks the China NB for its carefully considered comments on the IEEE
802.1X FDIS ballot.
• We note that IEEE 802 responded in 6N15607 to the comments by the China NB
in 6N15555. The referencing issues referred to by the China NB in this comment
will be addressed in responses specific to each issue using the process defined
by 6N15606. China NB representatives are invited to participate in the comment
resolution process.
• The IEEE 802 is unable to respond to the China NB comment that they are
“obliged to lose the responsibility and obligation of complying with and adopting
the standard” because this is outside the scope of IEEE 802.
Submission to SC6
Slide 4
December 2013
doc.: IEEE NNN
China NB comment CN.2 on IEEE 802.1X
China NB comment CN.2 on IEEE 802.1X
• The referenced RFC 2863 is Draft Standard that still requires additional or more
widespread field experience described in RFC 2026.
China NB proposed change CN.2 on IEEE 802.1X
• Delete the referenced RFC and related technology from the document.
Submission to SC6
Slide 5
December 2013
doc.: IEEE NNN
China NB comment CN.2 on IEEE 802.1X (cont)
IEEE 802 response to comment CN.2 on IEEE 802.1X
• RFC 2863 is The Interfaces Group MIB and is referenced because of the PAE MIB contained
in Clause 13.
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG will review
the references to ensure that only required references are included, RFC references are up to
date, and normative RFC references have an appropriate status.
• According to IETF RFC 2026, “A Draft Standard is at the second level of maturity within IETF.
A Draft Standard is a specification from which at least two independent and interoperable
implementations from different code bases have been developed, and for which sufficient
successful operational experience has been obtained.”
• IETF RFC 6410 merges Draft Standard and Internet Standard. However, it does not reclassify
Draft Standards to Proposed Standard status automatically. A Draft Standard may be
classified as a Proposed Standard if the IESG decides to do so. Or it may become an Internet
Standard if it meets the requirements of Section 2.2 of RFC 6410.
• For the purposes of IEEE 802 standards, IETF RFC 2863 is considered stable and it is
appropriate to reference it.
Submission to SC6
Slide 6
December 2013
doc.: IEEE NNN
China NB comment CN.3 on IEEE 802.1X
China NB comment CN.3 on IEEE 802.1X
• RFC 2869, 3394, 3410, 3579, 3580 and 4017 are Informational RFC that is
defined as a non-standard-track document in RFC 2026.
China NB proposed change CN.3 on IEEE 802.1X
• Delete the referenced RFC and related technology from the document.
Submission to SC6
Slide 7
December 2013
doc.: IEEE NNN
China NB comment CN.3 on IEEE 802.1X (cont)
IEEE 802 response to comment CN.3 on IEEE 802.1X
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included,
RFC references are up to date, and normative RFC references have an
appropriate status.
• According to IETF RFC 2026, “Specifications that have been prepared outside of
the Internet community and are not incorporated into the Internet Standards
Process by any of the provisions of section 10 may be published as Informational
RFCs, with the permission of the owner and the concurrence of the RFC Editor.
An "Informational" specification is published for the general information of the
Internet community.”
• It is appropriate to reference these published specifications in IEEE Standards.
• Additionally, see Clause 2 in the Downref Registry, RFC 3967 (BCP 97),
"Clarifying when Standards Track Documents may Refer Normatively to
Documents at a Lower Level", which specifies the rules for downward references
(DOWNREFs).
Submission to SC6
Slide 8
December 2013
doc.: IEEE NNN
China NB comment CN.4 on IEEE 802.1X
China NB comment CN.4 on IEEE 802.1X
• RFC 4346, 4675, 5216 and 5247 are Proposed Standards which are treated as
immature specifications by implementers required in RFC 2026.
China NB proposed change CN.4 on IEEE 802.1X
• Delete the referenced RFC and related technology from the document.
Submission to SC6
Slide 9
December 2013
doc.: IEEE NNN
China NB comment CN.4 on IEEE 802.1X (cont)
IEEE 802 response to comment CN.4 on IEEE 802.1X
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included,
RFC references are up to date, and normative RFC references have an
appropriate status.
• IETF Proposed Standards documents have been subject to open development
and review by the Internet technical community, generally including a number of
formal cross-discipline reviews including, specifically, a security review. This is
further strengthened in many cases by implementations and even the presence of
interoperable code. Hence IETF Proposed Standards are of such quality that
they are ready for the usual market-based product development and deployment
efforts into the Internet.
• The Kolkman draft (http://tools.ietf.org/id/draft-kolkman-proposed-standardsclarified-06.txt) is intended to clarify the interpretation of the maturity of a
Proposed Standard within IETF. It is currently under consideration by the IESG for
approval.
• It is appropriate to reference IETF Proposed Standards in IEEE Standards.
Submission to SC6
Slide 10
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.1 on IEEE 802.1X
Switzerland comment CH.1 on IEEE 802.1X
• We welcome and approve the submission of this outstanding global standard to
ISO/IEC because we take the view that global standards should be International
Standards, i.e. standards approved by ISO, IEC and ITU, respectively. IS approval
expresses the international consensus on the value of the standard.
• While the FDIS fast-track procedure invoked by the PSDO does not foresee a
resolution of comments before publication of the IS, the maintenance process of
ISO/IEC-approved standards must enable ISO NBs and IEC NCs to make
contributions which are duly considered by the maintenance body.
Submission to SC6
Slide 11
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.1 on IEEE 802.1X
(cont)
Switzerland comment CH.1 on IEEE 802.1X (cont)
• In Graz Resolution 6.1.10, ISO/IEC JTC1/SC6 has allocated responsibility for the
revision process of the ISO/IEC 8802-1 standards to the IEEE 802.1 WG under
the condition that SC 6 and its NBs have access to an established mechanism to
contribute to the revision process in the IEEE 802.1 WG.
• In 6N15606 the IEEE 802 JTC1 Standing Committee has replied by a proposal for
SC6 contributions to IEEE 802.1, 802.3 and 802.11 revision processes,
encouraging Sc6 NBs to comments on 802 drafts and standards before or after an
IEEE ballot closes.
• As our comments are submitted after closure of the IEEE ballot, we kindly ask the
IEEE 802.1 WG to process them, according to 6N15606, as soon as possible,
either during comment resolution on any subsequent draft of during normal
maintenance if balloting on the standard has completed..
Submission to SC6
Slide 12
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.1 on IEEE 802.1X
(cont)
IEEE 802 response to comment CH.1 on IEEE 802.1X
• IEEE 802 thanks the Switzerland NB for its carefully considered comments on the
IEEE 802.1X FDIS ballot, and assures the Switzerland NB that its comments will
be processed in a timely manner by the IEEE 802.1 WG using the mechanisms
defined and agreed in N15606. Swiss NB representatives are invited to participate
in the comment resolution process.
Submission to SC6
Slide 13
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.2 on IEEE 802.1X
Switzerland comment CH. 2 on IEEE 802.1X
• In a conventional DIS or DIS fast-track ballot, the subsequent comments would be
issued with a DISAPPROVE vote, which would be turned into APPROVAL if the
comments were satisfactorily resolved The FDIS fast-track however postpones, by
2.7 of the ISO/IEC Directives, Part 1, such resolution to the next review of the
standard. Furthermore, affirmative votes to an FDIS cannot be made conditional
on the resolution of any comments.
• However, as explained above, we wish ISO/IEC to endorse this standard and to
subjugate it under its maintenance procedures as set forth in F.2.4 of the ISO/IEC
Directives, Part 1, and Sc6 Graz Resolution 6.1.10.
• Therefore our vote is APPROVE, unconditionally. Our comments are submitted
under the late option of 6N15606 to be processed by the IEEE 802.1 WG as soon
as possible, i.e. either during comment resolution on any subsequent draft or
during normal maintenance.
IEEE 802 response to comment CH.2 on IEEE 802.1X
• See IEEE 802 response to Switzerland comment CH.1.
Submission to SC6
Slide 14
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.3 on IEEE 802.1X
Switzerland comment CH.3 on IEEE 802.1X
• When ISO/IEC/IEEE 8802-1X has been endorsed by ISO/IEC, then the ISO
Directives, Part 2, “Rules for the structure and drafting of International Standards”
as well as the JTC 1 Supplement and the relevant JTC 1 Standing Documents
must be considered. It is desirable that the next revision of the specification be in
line with the applicable requirements.
• This is a major aim of our comments. We will be pleased to find resolutions in
fruitful collaboration with the IEEE 802.1 WG.
IEEE 802 response to comment CH.3 on IEEE 802.1X
• IEEE 802.1X has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. However, mechanisms defined and
agreed in N15606 will apply
Submission to SC6
Slide 15
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.4 on IEEE 802.1X
Switzerland comment CH.4 on IEEE 802.1X
• Re: clause 2
• RFC 4017, 3580, 3579, 3410, 3394 and 2869 have only INFORMATIONAL status.
• According to RFC 2026 a specification of INFORMATIONAL status is a nonstandard-track document which is (cit.) “”not subject to the rules of Internet
standardization” and (cit.) “published for the general information of the Internet
community and does not represent an Internet community consensus or
recommendation. … Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity level or on non
standards track specifications other than referenced specifications from other
standards bodies.” (citation end)
• Therefore these documents do not qualify for normative referencing.
Switzerland proposed change CH.4 on IEEE 802.1X
• Resolve the issue by any of the following:
– Placing the reference into the Informative References section.
– Referencing of published standards, preferably ISO/IEC standards,
– Incorporation of technical requirements into the standard text,.
Submission to SC6
Slide 16
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.4 on IEEE 802.1X
(cont)
IEEE 802 response to comment CH.4 on IEEE 802.1X
• According to IETF RFC 2026, “Specifications that have been prepared outside of
the Internet community and are not incorporated into the Internet Standards
Process by any of the provisions of section 10 may be published as Informational
RFCs, with the permission of the owner and the concurrence of the RFC Editor.
An "Informational" specification is published for the general information of the
Internet community.”
• It is appropriate to reference these published specifications in IEEE Standards.
• Additionally, see Clause 2 in the Downref Registry, RFC 3967 (BCP 97),
"Clarifying when Standards Track Documents may Refer Normatively to
Documents at a Lower Level", which specifies the rules for downward references
(DOWNREFs).
Submission to SC6
Slide 17
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.5 on IEEE 802.1X
Switzerland comment CH.5 on IEEE 802.1X
• Re: clause 2
• RFC 2863 has been published in the year 2000 but is still at DRAFT STANDARD
status. According to RFC 6410 it will be re-classified as PROPOSED STANDARD
in October 2013. Therefore (see CH 6) it does not necessarily qualify for
normative referencing.
Submission to SC6
Slide 18
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.5 on IEEE 802.1X
(cont)
IEEE 802 response to comment CH.5 on IEEE 802.1X
• RFC 2863 is The Interfaces Group MIB and is referenced because of the PAE MIB
contained in Clause 13.
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included, RFC
references are up to date, and normative references have an appropriate status.
• According to IETF RFC 2026, “A Draft Standard is at the second level of maturity
within IETF. A Draft Standard is a specification from which at least two independent
and interoperable implementations from different code bases have been developed,
and for which sufficient successful operational experience has been obtained.”
• IETF RFC 6410 merges Draft Standard and Internet Standard. However, it does not
reclassify Draft Standards to Proposed Standard status automatically. A Draft
Standard may be classified as a Proposed Standard if the IESG decides to do so.
Or it may become an Internet Standard if it meets the requirements of Section 2.2 of
RFC 6410.
• For the purposes of IEEE 802 standards, IETF RFC 2863 is considered stable and
it is appropriate to reference it.
Submission to SC6
Slide 19
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.6 on IEEE 802.1X
Switzerland comment CH.6 on IEEE 802.1X
• Re: clause 2
• RFC 4675, 5216 and 5247 have been published in the year 2006, 2006, 2008 and
2008, respectively, but are still at PROPOSED STANDARD status.
• According to 4.1.1 of RFC 2026 (cit.) “a Proposed Standard specification is
generally stable, has resolved known design choices, is believed to be wellunderstood, has received significant community review, and appears to enjoy
enough community interest to be considered valuable. However, further
experience might result in a change or even retraction of the specification before it
advances. … Implementers should treat Proposed Standards as immature
specifications.” (citation end).
• By 2.2 of RFC 6410 (cit.) “An Internet Standard is characterized by a high degree
of technical maturity and by a generally held belief that the specified protocol or
service provides significant benefit to the Internet community.
Submission to SC6
Slide 20
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.6 on IEEE 802.1X
(cont)
Switzerland comment CH.6 on IEEE 802.1X
• The IESG, in an IETF-wide Last Call of at least four weeks, confirms that a
document advances from Proposed Standard to Internet Standard. The request
for reclassification is sent to the IESG along with an explanation of how the criteria
have been met. The criteria are:
– (1) There are at least two independent interoperating implementations with
widespread deployment and successful operational experience.
– (2) There are no errata against the specification that would cause a new
implementation to fail to interoperate with deployed ones.
– (3) There are no unused features in the specification that greatly increase
implementation complexity.
– (4) If the technology required to implement the specification requires patented or
otherwise controlled technology, then the set of implementations must
demonstrate at least two independent, separate and successful uses of the
licensing process.” (citation end)
Submission to SC6
Slide 21
December 2013
doc.: IEEE NNN
Switzerland NB comment CH. 6 on IEEE 802.1X
(cont)
Switzerland comment CH.6 on IEEE 802.1X
• Specifications will remain at PROPOSED STANDARD level if either no request to
reclassify them as INTERNET STANDARD is sent to the IESG or they fail to meet
one or more of these requirements.
• Specifications remaining at PROPOSED STANDARD level for more than four
years are either not known to meet the criteria for the INTERNET STANDARD
level or known to fail to meet some of them.
• According the Note in 4.2.4 to RFC 2026 (cit.) “Standards track specifications
normally must not depend on other standards track specifications which are at a
lower maturity level or on non standards track specifications other than referenced
specifications from other standards bodies.” (citation end). This principle also
applies to ISO/IEC standards and should as well be respected by IEEE standards.
• Therefore the PROPOSED STANDARD level is not a sufficient qualification for
normative referencing.
Submission to SC6
Slide 22
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.6 on IEEE 802.1X
(cont)
Switzerland proposed change CH.6 on IEEE 802.1X
• For each of these RFCs, chose one of the following alternative actions:
– Produce an RER according to JTC1 Standing Document N5, explaining whether
or not the RFC has been formally evaluated against the criteria for the
INTERNET STANDARD level, and if it has been evaluated, which criteria the
RFC fails to meet, furthermore why it is needed as a normative reference in the
IEEE 802.1X standard and how it is justified to allow a normative reference
though IETF does not award it INTERNET STANDARD level.
– Reference published standards, preferably ISO/IEC standards,
– Incorporate technical requirements into the standard text,
– Place the reference into the Informative References section
Submission to SC6
Slide 23
December 2013
doc.: IEEE NNN
Switzerland NB comment CH. 6 on IEEE 802.1X
(cont)
IEEE 802 response to comment CH.6 on IEEE 802.1X
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included,
RFC references are up to date, and normative RFC references have an
appropriate status.
• IETF Proposed Standards documents have been subject to open development
and review by the Internet technical community, generally including a number of
formal cross-discipline reviews including, specifically, a security review. This is
further strengthened in many cases by implementations and even the presence of
interoperable code. Hence IETF Proposed Standards are of such quality that
they are ready for the usual market-based product development and deployment
efforts into the Internet.
• The Kolkman draft (http://tools.ietf.org/id/draft-kolkman-proposed-standardsclarified-06.txt) is intended to clarify the interpretation of the maturity of a
Proposed Standard within IETF. It is currently under consideration by the IESG for
approval.
• It is appropriate to reference IETF Proposed Standards in IEEE Standards.
Submission to SC6
Slide 24
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.7 on IEEE 802.1X
Switzerland comment CH.7 on IEEE 802.1X
• Re: clause 2
• RFC 4346 has been obsoleted by RF 5246, which has been published in the year
2008 but is still at PROPOSED STANDARD status. Therefore it does not
necessarily qualify for normative referencing
Switzerland proposed change CH.7 on IEEE 802.1X
• Find a resolution for RFC 5246 as indicated in CH6.
IEEE 802 response to comment CH.7 on IEEE 802.1X
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included,
RFC references are up to date, and normative RFC references have an
appropriate status.
Submission to SC6
Slide 25
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.8 on IEEE 802.1X
Switzerland comment CH.8 on IEEE 802.1X
• Re: clause 2
• FIPS and NIST do not have ARO status. The related references do not meet the
requirements of JTC1 Standing Document N5
Switzerland proposed change CH.8 on IEEE 802.1X
• Reference ISO/IEC standards where available (e.g. for the AES) or provide RERs
as required.
IEEE 802 response to comment CH.8 on IEEE 802.1X
• IEEE 802.1X has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. The mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 26
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.9 on IEEE 802.1X
Switzerland comment CH.9 on IEEE 802.1X
• Re: clause 3
• The definitions are unnumbered and the phrasing of most of them does not
conform to the ISO/IEC Directives, Part 2
Switzerland proposed change CH.9 on IEEE 802.1X
• Number all definitions. Discard articles (“a”, “the”) at the beginning of the
definition. Avoid two or more sentences (such as in Authentication Server).
Discard Notes.
IEEE 802 response to comment CH.9 on IEEE 802.1X
• IEEE 802.1X has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. The mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 27
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.10 on IEEE 802.1X
Switzerland comment CH.10 on IEEE 802.1X
• Re: clause 5.22, Table 5-1
• This table fails to include the Authentication Server which, by clause 3, can be
located in a component separate from the component hosting the Authenticator.
See also CH 11.
Switzerland proposed change CH.10 on IEEE 802.1X
• Include the Authentication Server into Table 5-1..
IEEE 802 response to comment CH.10 on IEEE 802.1X
• An Authentication Server is not necessary for a network that deploys IEEE 802.1X
and therefore is not included in this conformance clause.
Submission to SC6
Slide 28
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.11 on IEEE 802.1X
Switzerland comment CH.11 on IEEE 802.1X
• Re: clause 5
• This clause specifies requirements and options for the Supplicant and the
Authenticator, but none for the Authentication Server, neither explicitly nor through
normative references.
• According to paragraph 3 of 1.3 (cit.) “this standard specifies the use of EAP … to
support authentication using a centrally administered Authentication server …”.
This wording sketches a configuration with a centralized Authentication Server
component providing (by definition) authentication services to a multitude of
Authenticator components.
• To be trusted for the provision of secure authentication services the Authentication
Server itself must be secure. The security requirements however are not specified
in this standard.
• See also CH.13 cc.
Submission to SC6
Slide 29
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.11 on IEEE 802.1X
(cont)
Switzerland NB proposed change CH.11 on IEEE 802.1X
• Specify requirements and options for the Authentication Server..
IEEE 802 response to comment CH.11 on IEEE 802.1X
• The Authentication Server is a system role within EAP and the EAP specifications
are referenced for the requirements.
Submission to SC6
Slide 30
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.12 on IEEE 802.1X
Switzerland NB comment CH.12 on IEEE 802.1X
• Re: clause 6.3.1
• RFC 3748 is referenced here, but the reference is not listed in clause 2. However,
RFC 3748 has been published in the year 2004 but is still at PROPOSED
STANDARD status. Therefore it does not necessarily qualify for normative
referencing
Switzerland NB proposed change CH.12 on IEEE 802.1X
• See CH6.
IEEE 802 response to comment CH.12 on IEEE 802.1X
• As part of the normal maintenance process for IEEE 802.1X, the IEEE 802.1 WG
will review the references to ensure that only required references are included,
RFC references are up to date, and normative RFC references have an
appropriate status.
Submission to SC6
Slide 31
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.13.1 on IEEE 802.1X
Switzerland NB comment CH.13.1 on IEEE 802.1X
• Re: clause 6.3.1
• The text does not explicitly specify what security goals the authentication
exchange claims to achieve.
• By the definition in clause 3 the Authentication Server performs authentication and
access control of the Supplicant. By clause 8.11, EAP methods used by the PAE
shall provide mutual authentication. By 5.6.b therefore the Authentication Server is
authenticated to the Supplicant.
• The definition of the Authentication Server indicates the claim that the
authentication exchange provides mutual authentication of Authenticator and
Supplicant if the MKA option is used, nothing otherwise. However, this can only be
guessed but is not explicitly specified.
• The normative references of this standard do not provide the necessary explicit
statements.
• Any security standard must explicitly state the security goals claimed to be
achieved, depending from the options chosen.
Submission to SC6
Slide 32
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.13.1 on IEEE 802.1X
(cont)
Switzerland NB proposed change CH.13.1 on IEEE 802.1X
• State explicitly all security goals claimed to be achieved by the authentication
exchange for each of the three roles and their pairwise relationships..
IEEE 802 response to comment CH.13.1 on IEEE 802.1X
• The three roles listed are potential parties to an authentication exchange. IEEE
802 does not understand what the Swiss NB is unclear about the goals of an
authentication exchange; the goal of an authentication exchange is to perform
authentication (see the definitions).
Submission to SC6
Slide 33
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.13.2 on IEEE 802.1X
Switzerland NB comment CH.13.2 on IEEE 802.1X
• Re: clause 6.3.1
• Neither this standard nor its normative references specify normative requirements
for the securing of the exchange between Authentication Server and
Authenticator.
• Unless the exchange between Authentication Server and Authenticator is
appropriately secured, the mutual authentication of Authentication Server and
Supplicant is not transferred the Authenticator and not linked to the 4-wayhandshake. The protocol thus fails to provide mutual authentication of Supplicant
and Authenticator.
• See 6N15523 for an analysis.
• What security mechanisms are appropriate strongly depends on the configuration
(centralized AS or collocated with the Authenticator) and the related security
assumptions and requires further analysis. As according to 1.3 this standard
targets a configuration with a centralized Authentication Server, it must include the
security requirements for the centralized configuration..
Submission to SC6
Slide 34
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.13.2 on IEEE 802.1X
(cont)
Switzerland NB comment CH.13.2 on IEEE 802.1X
• While it is acceptable to exclude specific security mechanisms and protocols for
the exchange between Authentication Server and Authenticator from this
standard, the standard must include normative security requirements. Otherwise
the standard is incomplete
Switzerland NB proposed change CH.13.2 on IEEE 802.1X
• Specify the normative security requirements of the exchange between the
Authentication Server and the Authenticator if they are not co-located..
IEEE 802 response to comment CH.13.2 on IEEE 802.1X
• Communication between Authenticator and Authentication Server is outside the
scope of this standard therefore it is inappropriate to include technical
requirements. However, the IETF RFCs for EAP and EAP in RADIUS are
referenced and can be consulted for further details.
Submission to SC6
Slide 35
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.14 on IEEE 802.1X
Switzerland NB comment CH.14 on IEEE 802.1X
• Re: clause 8.11
• This clause allows for a variety of EAP methods.
• Neither this standard nor its normative references specify the risks of the allowed
EAP methods.
• 6N15523 and 6N15613 have pointed out attacks possible in case of the use of the
strongest EAP methods (mutual authentication based on asymmetric
cryptography). It may be the case that other authentication methods allowed by
this clause have even more weaknesses.
• This standard must not allow EAP methods without stating the associated known
risks.
Submission to SC6
Slide 36
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.14 on IEEE 802.1X
(cont)
Switzerland NB proposed change CH.14 on IEEE 802.1X
• Analyse all authentication methods allowed by 8.11 and either discard them from
the standard or specify their risks
IEEE 802 response to comment CH.14 on IEEE 802.1X
• 6N15523 and 6N15613 do not present any valid attacks. The “attacks” described
were reviewed and technical arguments against their effectiveness were
presented in 6N15646 and 6N15658 at the meeting in Seoul in June 2013.
• IEEE 802.1X is restricted to using EAP methods that provide mutual
authentication and have the characteristics described in Clause 8.11.1.
Submission to SC6
Slide 37
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.15 on IEEE 802.1X
Switzerland NB comment CH.15 on IEEE 802.1X
• Re: clause 8.11
• Neither the specification nor its normative references provide a comprehensive list
of the allowed authentication methods. Unless all allowed authentication methods
are known and their security is well understood the security of this standard
cannot be assessed. Should certain authentication methods fail to meet the
security goals of this standard, then the standard would not meet its security
goals.
Switzerland NB proposed change CH.15 on IEEE 802.1X
• List all allowed authentication methods and exclude methods implied by 8.11 and
its normative references if they are not sufficiently secure..
Submission to SC6
Slide 38
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.15 on IEEE 802.1X
(cont)
IEEE 802 response to comment CH.15 on IEEE 802.1X
• A list of all allowed authentication methods is beyond the scope of this standard.
• The scope of IEEE 802.1X is to
– Specify a general method for provision of port-based network access control.
– Specify protocols that establish secure associations for IEEE Std 802.1AE™
MAC Security.
– Facilitate the use of industry standard authentication and authorization
protocols.
• Furthermore, the standard specifies the use of EAP to support authentication
using a centrally administered Authentication Server and defines EAP
encapsulation over LANs (EAPOL) to convey the necessary exchanges between
peer PAEs attached to a LAN.
Submission to SC6
Slide 39
December 2013
doc.: IEEE NNN
China NB comment CN.1 on IEEE 802.1AE
China NB comment CN.1 on IEEE 802.1AE
• Since the procedural and technical concerns China NB proposed in 6N15556 still
haven’t reasonably disposed in this FDIS text, and referencing issues mentioned
below exist in this text, so China NB has to vote against on this FDIS ballot. If
these issues could not be disposed reasonably and this proposal passes the FDIS
ballot, it is regretful for China to be obliged to lose the responsibility and obligation
of complying with and adopting the standard. Furthermore, China NB wishes to
state for the record.
Submission to SC6
Slide 40
December 2013
doc.: IEEE NNN
China NB comment CN.1 on IEEE 802.1AE (cont)
IEEE 802 response to comment CN.1 on IEEE 802.1AE
• IEEE thanks the China NB for its carefully considered comments on the 802.1AE
FDIS ballot
• We note that the IEEE 802 responded in N15608 to the comments by the China in
N15556. The referencing issues referred to by the China NB in this comment will
be addressed in responses specific to each issue using the process defined by
N15606. China NB representatives are invited to participate in the comment
resolution process.
• The IEEE 802 is unable to respond to the China NB comment that they are
“obliged to lose the responsibility and obligation of complying with and adopting
the standard” because the IEEE 802 is not party to any treaty or other obligations
of China.
Submission to SC6
Slide 41
December 2013
doc.: IEEE NNN
China NB comment CN.2 on IEEE 802.1AE
China NB comment CN.2 on IEEE 802.1AE
• The referenced RFC 2863 is Draft Standard that still requires additional or more
widespread field experience described in RFC 2026.
China NB proposed change CN.2 on IEEE 802.1AE
• Delete the referenced RFC and related technology from the document
Submission to SC6
Slide 42
December 2013
doc.: IEEE NNN
China NB comment CN.2 on IEEE 802.1AE (cont)
IEEE 802 response to comment CN.2 on IEEE 802.1AE
• RFC 2863 is The Interfaces Group MIB and is referenced because of the PAE
MIB contained in Clause 13.
• As part of the normal maintenance process for IEEE 802.1AE, the IEEE 802.1
WG will review the references to ensure that only required references are
included, RFC references are up to date, and normative RFC references have an
appropriate status.
• According to IETF RFC 2026, “A Draft Standard is at the second level of maturity
within IETF. A Draft Standard is a specification from which at least two
independent and interoperable implementations from different code bases have
been developed, and for which sufficient successful operational experience has
been obtained. “
• IETF Draft Standards are stable and it is appropriate to reference them in IEEE
Standards.
Submission to SC6
Slide 43
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.1 on IEEE 802.1AE
Switzerland NB comment CH.1 on IEEE 802.1AE
• We welcome and approve the submission of this outstanding global standard to
ISO/IEC because we take the view that global standards should be International
Standards, i.e. standards approved by ISO, IEC and ITU, respectively. IS
approval expresses the international consensus on the value of the standard.
• While the FDIS fast-track procedure invoked by the PSDO does not foresee a
resolution of comments before publication of the IS, the maintenance process of
ISO/IEC-approved standards must enable ISO NBs and IEC NCs to make
contributions which are duly considered by the maintenance body.
• In Graz Resolution 6.1.10, ISO/IEC JTC1/SC6 has allocated responsibility for the
revision process of the ISO/IEC 8802-1 standard to the IEEE 802.1 WG under the
condition that SC 6 and its NBs have access to an established mechanism to
contribute to the revision process in the IEEE 802.1 WG..
Submission to SC6
Slide 44
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.1 on IEEE 802.1AE
(cont)
Switzerland NB comment CH.1 on IEEE 802.1AE (cont)
• In 6N15606 the IEEE 802 JTC1 Standing Committee has replied by a proposal for
SC6 contributions to IEEE 802.1, 802.3 and 802.11 revision processes,
encouraging Sc6 NBs to comments on 802 drafts and standards before or after an
IEEE ballot closes.
• As our comments are submitted after closure of the IEEE ballot, we kindly ask the
IEEE 802.1 WG to process them, according to 6N15606, as soon as possible,
either during comment resolution on any subsequent draft of during normal
maintenance if balloting on the standard has completed
IEEE 802 response to comment CH.1 on IEEE 802.1AE
• IEEE 802 thanks the Switzerland NB for its carefully considered comments on the
IEEE 802.AE FDIS ballot, and assures the Switzerland NB that its comments will
be processed in a timely manner by the IEEE 802.1 WG using the mechanisms
defined and agreed in N15606. Swiss NB representatives are invited to participate
in the comment resolution process.
Submission to SC6
Slide 45
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.2 on IEEE 802.1AE
Switzerland NB comment CH.2 on IEEE 802.1AE
• In a conventional DIS or DIS fast-track ballot, the sub-sequent comments would
be issued with a DISAPPROVE vote, which would be turned into APPROVAL if
the comments were satisfactorily resolved.
• The FDIS fast-track however postpones, by 2.7 of the ISO/IEC Directives, Part 1,
such resolution to the next review of the standard. Furthermore, affirmative votes
to an FDIS cannot be made conditional on the resolution of any comments.
• However, as explained above, we wish ISO/IEC to endorse this standard and to
subjugate it under its maintenance procedures as set forth in F.2.4 of the ISO/IEC
Directives, Part 1, and Sc6 Graz Resolution 6.1.10.
• Therefore our vote is APPROVE, unconditionally. Our comments are submitted
under the late option of 6N15606 to be processed by the IEEE 802.1 WG as soon
as possible, i.e. either during comment resolution on any subsequent draft or
during normal maintenance.
Submission to SC6
Slide 46
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.2 on IEEE 802.1AE
(cont)
IEEE 802 response to comment CH.2 on IEEE 802.1AE
• IEEE 802 thanks the Switzerland NB for its carefully considered comments on the
IEEE 802.1AE FDIS ballot, and assures the Switzerland NB that its comments will
be processed in a timely manner by the IEEE 802.1 WG using the mechanisms
defined and agreed in N15606. Swiss NB representatives are invited to participate
in the comment resolution process.
Submission to SC6
Slide 47
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.3 on IEEE 802.1AE
Switzerland NB comment CH.3 on IEEE 802.1AE
• When the ISO/IEC/IEEE 8802-1AE standard has been endorsed by ISO/IEC, then
the ISO Directives, Part 2, “Rules for the structure and drafting of International
Standards” as well as the JTC 1 Supplement and the relevant JTC 1 Standing
Documents must be considered. It is desirable that the next revision of the
specification be in line with the applicable requirements.
• This is a major aim of our comments. We will be pleased to find resolutions in
fruitful collaboration with the IEEE 802.1 WG.
IEEE 802 response to comment CH.3 on IEEE 802.1AE
• IEEE 802.1AE has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. However, mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 48
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.4 on IEEE 802.1AE
Switzerland NB comment CH.4 on IEEE 802.1AE
• Clause 2
• The reference to the publication by McGrew and Viega is not admitted by the ISO
Directives
Switzerland NB proposed change CH.4 on IEEE 802.1AE
• Reference ISO/IEC 19772 and specify the parameters in the standard text
IEEE 802 response to comment CH.4 on IEEE 802.1AE
• The reference to the publication was removed in IEEE 802.1AEbn-2011
amendment. Note that the final version of IEEE 802.1AEbn-2011 has been
forwarded to ISO/IEC JTC1 SC6 under the PSDO agreement.
Submission to SC6
Slide 49
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.5 on IEEE 802.1AE
Switzerland NB comment CH.5 on IEEE 802.1AE
• Clause 2
• FIPS does not have ARO status. The reference to FIPS 197 does not meet the
requirements of JTC1 Standing Document N5
Switzerland NB proposed change CH.5 on IEEE 802.1AE
• Reference ISO/IEC 18033-3.
IEEE 802 response to comment CH.5 on IEEE 802.1AE
• IEEE 802.1AE has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. The mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 50
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.6 on IEEE 802.1AE
Switzerland NB comment CH.6 on IEEE 802.1AE
• Clause 2
• Old versions of IEEE Std. 802.1D, 1Q, 1X, 1ad and 1AB are referenced
Switzerland NB proposed change CH.6 on IEEE 802.1AE
• Reference the actual versions or use undated references.
IEEE 802 response to comment CH.6 on IEEE 802.1AE
• This and other updates will be considered as part of the regular editing and
maintenance process within IEEE 802.1.
• The references to IEEE Std. 802.1Q-2005, IEEE Std 802.1X-2004, and IEEE Std
802.1ad-2005 have been updated in IEEE 802.1AEbn-2011 amendment. Note
that the final version of IEEE 802.1AEbn-2011 has been forwarded to ISO/IEC
JTC1 SC6 under the PSDO agreement.
Submission to SC6
Slide 51
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.7 on IEEE 802.1AE
Switzerland NB comment CH.7 on IEEE 802.1AE
• Clause 2
• IEEE Std 802.11 has been published as ISO/IEC/IEEE 802-11
Switzerland NB proposed change CH.7 on IEEE 802.1AE
• Reference the actual versions or use undated references.
IEEE 802 response to comment CH.7 on IEEE 802.1AE
• This and other updates will be considered as part of the regular editing and
maintenance process within IEEE 802.1.
• IEEE 802.1AE has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. The mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 52
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.8 on IEEE 802.1AE
Switzerland NB comment CH.8 on IEEE 802.1AE
• IEEE Std 802.11i has been included in the 2012 edition of the 802.11 standard,
which is referenced by this standard. The reference to 802.11i is therefore not
needed
Switzerland NB proposed change CH.8 on IEEE 802.1AE
• Delete the reference.
IEEE 802 response to comment CH.8 on IEEE 802.1AE
• This will be considered as part of the regular editing and maintenance process
within the IEEE 802.1 WG.
Submission to SC6
Slide 53
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.9 on IEEE 802.1AE
Switzerland NB comment CH.9 on IEEE 802.1AE
• Clause 2
• Same as Switzerland comment 5 on IEEE 802.1X
• RFC 2863 has been published in the year 2000 but is still at DRAFT STANDARD
status. According to RFC 6410 it will be re-classified as PROPOSED STANDARD
in October 2013….
Switzerland NB proposed change CH.9 on IEEE 802.1AE
• For each of these RFCs, chose one of the following alternative actions…
Submission to SC6
Slide 54
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.9 on IEEE 802.1AE
(cont)
IEEE 802 response to comment CH.9 on IEEE 802.1AE
• RFC 2863 is The Interfaces Group MIB and is referenced because of the PAE
MIB contained in Clause 13.
• As part of the normal maintenance process for IEEE 802.1AE, the IEEE 802.1
WG will review the references to ensure that only required references are
included, RFC references are up to date, and normative RFC references have an
appropriate status.
• Additionally, according to IETF RFC 2026, “A Draft Standard is at the second level
of maturity within IETF. A Draft Standard is a specification from which at least two
independent and interoperable implementations from different code bases have
been developed, and for which sufficient successful operational experience has
been obtained. “
• IETF Draft Standards are stable and it is appropriate to reference them in IEEE
Standards.
Submission to SC6
Slide 55
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.10 on IEEE 802.1AE
Switzerland NB comment CH.10 on IEEE 802.1AE
• Clause 3
• The phrasing of most definitions does not conform to the ISO/IEC Directives, Part
2
Switzerland NB proposed change CH.10 on IEEE 802.1AE
• Discard articles (“a”, “the”) at the beginning of the definition. Avoid two or more
sentences (such as in 3.13). Discard Notes.
IEEE 802 response to comment CH.10 on IEEE 802.1AE
• IEEE 802.1AE has been developed according to the IEEE Standards Association
standards development process and IEEE-SA Standards Style Manual. Editing
and maintenance will continue to be the responsibility of IEEE 802 and will
conform to the IEEE policies and procedures. The mechanisms defined and
agreed in N15606 will apply.
Submission to SC6
Slide 56
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.11 on IEEE 802.1AE
Switzerland NB comment CH.11 on IEEE 802.1AE
• Clause 3.10
• While MAC-SEC is not for use by ISO/IEC/IEEE 8802-11, the text makes
reference to IEEE STD 802.11 in this definition as well as in several other places.
Though there is nothing wrong with these references, they may be misunderstood
to assume that MAC-SEC could be used in wireless networks
Switzerland NB proposed change CH.11 on IEEE 802.1AE
• Add a clarifying footnote to each reference to 802.11..
IEEE 802 response to comment CH.11 on IEEE 802.1AE
• Clause 3.10 is the definition of a LAN (generic) and provides examples of what an
IEEE 802 LAN may be. IEEE 802.11 wireless LANs are considered to be
conformant with the definition of an IEEE 802 LAN.
• The 'Relationship between IEEE Std 802.1AE and other IEEE 802 standards’ on
page iv of 802.1AE-2006 makes it clear that IEEE 802.1AE is not intended for use
with IEEE 802.11 (even though that would be possible as you say).
Submission to SC6
Slide 57
December 2013
doc.: IEEE NNN
Switzerland NB comment CH.12 on IEEE 802.1AE
Switzerland NB comment CH.12 on IEEE 802.1AE
• Clause 6.9
• MACsec does not support message sequence integrity and thus not provide full
connection mode data integrity. More specifically, it does not protect against
message removal
Switzerland NB proposed change CH.12 on IEEE 802.1AE
• Append an exclusion after h).
IEEE 802 response to comment CH.12 on IEEE 802.1AE
• IEEE 802.1AE does not claim to provide connection mode data integrity.
• The MAC Service as defined by ISO/IEC 15802-1 : 1995 (revision in
progress as IEEE P802.1AC) is a connectionless-mode service. The
purpose of IEEE 802.1AE is to secure the MAC Service and not any other service;
the question of connection mode data integrity does not
therefore arise. See '1.2 Scope' first sentence on page 2.
Submission to SC6
Slide 58