> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Klaas Wierenga > Sent: Monday, August 11, 2008 8:20 AM > To: emu@ietf.org > Subject: [Emu] Review of Requirements for an Tunnel Based EAP Method > > 1. intro > > reference for PEAP is missing, too bad the drafts have expired... > [Joe] Still looking for a reference.
> 3.8 resource constrained environments > > This is a bit a fuzzy paragraph. I feel that the SHOULD here > invites for developing 'weaker' methods in order to satisfy > this goal. I would prefer to leave this out altogether. As an > alternative you might want to describe a situation in which > the use of a weaker method may be mitigated by reducing the > services that are made available to these resource challenged devices. > [Joe] Yup, this needs discussion. > 4.2.1.4 peer identity privacy > > just username is too limited, all credentials need to be > protected, and arguably all attributes of a user. > [Joe] Agreed, we should cover that. > 4.4 EAP Channel Binding Requirements > > Such attacks...., in which key channel binding > characteristics are transported.... > > I think it is not the 'key channel binding characteristics' > that are transported but rather the 'service > characteristics'. I prefer the wording in clancy-emu-chbind: > > " [...] a process in which the EAP client provides > information about the characteristics of the service > provided by the > authenticator to the AAA server protected within the EAP method, > allowing the server to verify the authenticator is providing valid > information to the peer. The server can also respond back with > additional information that could be useful for the > client to decide > whether or not to continue its session with the authenticator." > [Joe] This section should really reference the channel bindings draft. > 4.5 Requirements associated with carrying usernames/passwords > > OTP is not a password database. > [Joe] OK, will add password verifiers. > 4.5.1.2 authentication of server > > I don't think it is as important to protect the username as > the password. > [Joe] OK we can change the text to indicate that. > 4.5.1.3 server credential revocation checking > > Perhaps with the exception of the Grid community there is no > use of OCSP (let alone SCVP) as far as I know, and popular > implementations of SSL don't implement it. I understand the > requirement but I am afraid this is too restrictive and may > be prohibitive for implementers. I would suggest changing the > MUST to SHOULD and leave out the paragraph about OCSP and SCVP. > [Joe] It is important to have a mechanism to check for certificate revocation before any sensitive data is sent in the TLS tunnel. The current text states "... the tunnel method MUST support mechanisms to check the revocation status of a credential. The tunnel method SHOULD make use of Online Certificate Status Protocol (OCSP) [RFC2560] or Server-based Certificate Validation Protocol (SCVP) [RFC5055] to obtain the revocation status of the EAP server certificate." I believe that these text meets the security requirement and does not constrain the design to OCSP or SCVP (if it turned out to be advantageous then potentially a CRL mechanism can be used). > 4.6.3 cryptographic binding with TLS tunnel > > expand CTK, MSK, EMSK, TEK > > expand "domino effects" > ____ [Joe] OK ___________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
