An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol
RFC 6124
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert No Objection
(Russ Housley; former steering group member) (was Discuss, Yes) Yes
(Adrian Farrel; former steering group member) No Objection
I couldn't work out which range of EAP Method Types should be used for the allocation described at the head of Section 7 for "EAP-EKE Version 1". I presume you are headed for 1-191 or 256-... The difference at this stage is whether expert review needs to be invoked.
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries.
4.2.3. The EAP-EKE-Confirm Payload
PNonce_PS/PNonce_S:
This field ("proptected nonce") contains the encrypted and
typo: protected
integrity-protected response to the other party's challenge, see
Section 5.3 and Section 5.4. Similarly to the PNonce_P field,
this field's size is determined by the encryption and MAC
algorithms.
The following used to be a DISCUSS:
7.5. Identity Type Registry
In addition, an identity type registry is defined:
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
Is this value ever entered by a human? If the answer is yes, then this need some common user friendly input format for management of such identities.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Russ and Tim's DISCUSS positions.
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection