| 2014-05-14 |
May 2014 Interim |
Request evalutaion by Security TG |
Technical experts review |
|
| 2014-07-17 |
Jul 2014 Plenary |
No update |
Technical experts review |
|
| 2014-07-17 |
Sep 2014 Interim |
No update |
Technical experts review |
|
| 2014-07-17 |
Nov 2014 Plenary |
No update |
Technical experts review |
|
| 2015-01-13 |
Jan 2015 Interim |
No change necessary unless other changes require it. |
Technical experts review |
|
| 2015-01-13 |
Mar 2015 Plenary |
No change necessary unless other changes require it. |
Technical experts review |
|
| 2015-01-13 |
May 2015 Interim |
No change necessary unless other changes require it. |
Technical experts review |
|
| 2015-01-13 |
Jul 2015 Plenary |
No change necessary unless other changes require it. |
Technical experts review |
|
| 2017-01-17 |
Jan 2017 Interim |
Security TG will review this item this week make a decision. |
Technical experts review |
|
| 2017-03-14 |
Mar 2017 Plenary |
Reject, this an enhancement request that does raise interoperability and implementation issues and there is no compelling reason to make the change at present.
The 802.1 Security Task Group repeated its review of this maintenance item in during the January 2017 meeting 802.1 meeting and concluded that this item could be closed at this time, and that the Closed item in the Maintenance Database would be a sufficient reminder to check that advances in cryptographic research had not indicated that we should replace the current CMAC based KDF. The latter was adopted prior to the publication of RFC 5869 (HKDF), with the best advice available to us at that time. The issues of specification revision and interoperability previously noted in our reviews of this item might well mean that the existing implementations would not (in the absence of demonstrated compelling deficiency/security exposure attributable to the current KDF) be upgraded to use the new KDF, with the result that interoperability issues could be persistent with new implementations having to include both KDFs and frequently downgrade. RFC 5869 itself says that it "is not intended as a call to change existing protocols". Further 802.1X itself does not currently call for the use of HMAC or SHA for other reasons, and implementations may lack a high performance SHA-256 capability, while the CMAC KDF uses AES which is currently required and where MACsec is supported (which is what the KDF is for) requires a very high performance AES engine (which may well be accessible for KDF computation). So remaining with the current KDF is desirable for both code size and performance reasons.
|
Rejected |
|