In adding the tunneling method to the charter we need to make sure we work off a valid set of requirements. We have a set of requirements that are based on tunneling passwords:
1. Transport of encrypted password for support of legacy password databases (REQUIRED) 2. Mutual authentication (specifically authentication of the server) (REQUIRED) 3. resistance to offline dictionary attacks, man-in-the-middle attacks (REQUIRED) 4. Compliance with RFC 3748, RFC 4017 and EAP keying (including EMSK and MSK generation) (REQUIRED) 5. Peer identity confidentiality (REQUIRED) 6. Crypto agility and ciphersuite negotiation (REQUIRED) 7. Session resumption (no password needed) (REQUIRED) 8. Fragmentation and reassembly (REQUIRED) 9. Cryptographic binding (REQUIRED if additional inner mechanisms are supported) 10. Password/PIN change (DESIRABLE) 11. Transport Channel binding data (REQUIRED) 12. Protected result indication (REQUIRED) 13. Support for certificate validation protocols (DESIRABLE) 14. Extension mechanism (in support of 10 - 12) (REQUIRED) In addition we should consider requirements in the use of the tunneling and changes to the behavior introduced by tunneling: 1. Tunneling EAP methods for authentication (eg, chaining, result indication, etc.) 2. Additional data that needs to be tunneled (channel binding, etc.) 3. Extensibility 4. Additional requirements for the tunnel itself 5. Changes to the above requirements (required to meet 3748, 4017, eap keying etc.) Are there specific items to be added or changed in the original list based on these areas? Are there other areas we need to consider when looking for requirements? _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
