Subject: Re: [Emu] Review of emu-eaptunnel-req-00, chunk 1

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 30 Oct 2008 17:24:33 -0700

Hi Stefan,

Thanks for doing this review.  Comments inline below  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stefan Winter
> Sent: Friday, August 08, 2008 7:10 AM
> To: [email-masked]
> Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 1
> 
> Abstract
> ------------
> 
> "The tunnel will provide support for password authentication, 
> EAP authentication and the transport of additional data for 
> other purposes." 
> This wording excludes means of authentication that are 
> neither based on passwords nor EAP (while it should be 
> invariant to the tunnel what's transported inside). Suggest 
> to re-word to ... provide support for authentication (both 
> EAP and non-EAP) and the transport of additional data for 
> other purposes.
> 
[Joe] I think this will need more discussion.  While the tunnel can carry lots of different things I think we need to focus on a constrained set.  We started with just passwords and then added EAP methods.  This could be future work, I don't think we need (or want)  to tackle it now. 

> 1. Introduction
> ----------------
> 
> The second sentence misses a reference behind PEAP.
> 
[Joe] Anybody have a reference for PEAP? 

> 2. Conventions
> ---------------------
> 
> Looking at RFC2119, it seems that that RFC is well applicable 
> also to non-standards-track RFCs. ("Key words for use in RFCs 
> to Indicate Requirement Levels", "This document defines these 
> words as they should be interpreted in IETF documents.") Is 
> it really necessary to create an own wording definition here?
> 
[Joe] The issue isn't between standard and non standard, but rather between protocol vs. requirements.  We are following the same conventions as NEA so these are not totally new. 

> 3.1 Password Auth
> --------------------------
> 
> "support for minimal management tasks including password 
> change". I fail to see why a management mechanism to *change* 
> the password is needed
> *during* the authentication... ?
> 
[Joe] This was indicated as useful as in some systems the user may not be able to fully authenticate before they change their password. 

> 3.4 Id Protection
> ----------------------
> 
> The intent of this section is unclear to me.
> 
> "... If an inner method also provides identity protection, 
> this protection
>    MUST extend all the way to the server that terminates that inner
>    method. "
> 
> ... "this" refers to which method, the inner or the outer? If
> 
> outer) it appears impossible to me that the outer tunnel can 
> possibly ensure that the id protection extends beyond its 
> termination point, up to the endpoint of the inner
> inner) this would put a requirement on the inner method, 
> which appears odd in document that should describe 
> requirements for the outer method.
> 
[Joe] I agree this is a bit strange, perhaps we can remove this sentence. 

> 3.8 Resource constrained Environments
> -------------------------------------
> 
> The document has the implicit requirement to use TLS for the 
> tunnel method, which is computationally intensive in itself. 
> A device which is able to establish a TLS tunnel apparently 
> has a decent amount of computational resources. Plus, the 
> definition of resource contrained device is quite fuzzy: 
> "little" processing power, "small" memory, "small" amount of 
> storage. This section doesn't add a lot of value to the 
> document IMHO. I suggest to delete it altogether.
> 
[Joe] This needs more discussion.

> 
> 4.1.1 RFC compliance
> -------------------------------
> 
> This section can be largely condensed. It references RFC4017 
> as a mandatory reference and requires unconditional 
> compliance to that RFC, but repeats parts of the content of 
> that RFC in a different wording, which appears redundant. 
> [SW] annotated full text of section below:
> 
> The tunnel method MUST include a Security Claims section with all
>    security claims specified in Section 7.2 in RFC 3748 [RFC3748].  In
>    addition, it MUST meet the requirement in Sections 2.1 and 
> 7.4 of RFC
>    3748 that tunnel methods MUST support protection against 
> man-in-the-
>    middle attacks.  Furthermore, all tunnel methods MUST support
>    identity protection as specified in Section 7.3 in RFC 3748.
> 
> [SW] Sentence 2 (MITM protection) is already contained in 
> item [6] in RFC4017. Suggest to to delete sentence.
> [SW] Sentence 3 (id prot) is already contained in item [9] in 
> RFC4017. Suggest to to delete sentence.
> 
> 
>    The tunnel method MUST be unconditionally compliant with RFC 4017
>    [RFC4017] (using the definition of "unconditionally compliant"
>    contained in section 1.1 of RFC 4017).  This means that the method
>    MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT
>    requirements in RFC 4017.
> 
>    The tunnel method MUST meet all the EAP method 
> requirements contained
>    in the EAP Key Management Framework draft [I-D.ietf-eap-keying] or
>    its successor.  The tunnel method MUST include MSK and EMSK
>    generation.  This will enable the tunnel method to 
> properly fit into
>    the EAP key management framework, maintaining all of the security
>    properties and guarantees of that framework.
> 
> [SW] MSK and EMSK generation are already contained in item 
> [2] in RFC4017. Suggest to delete the last two sentences.
> 
>    The tunnel method MUST NOT be tied to any single cryptographic
>    algorithm.  Instead, it MUST support run-time negotiation to select
>    among an extensible set of cryptographic algorithms.  This
>    "cryptographic algorithm agility" provides several 
> advantages.  Most
>    important, when a weakness in an algorithm is discovered 
> or increased
>    processing power overtakes an algorithm, users can easily 
> transition
>    to a new algorithm.  Also, users can choose the algorithm that best
>    meets their needs.
> 
> [SW] Algorithm independence is already contained in item [7] 
> of RFC4017. The wording isn't so clear to me, but at least 
> the Security Considerations section in RFC4017 claims that it 
> is the case. Suggest to delete the para.
> 
>    The tunnel method MUST meet requirements pertinent to EAP method
>    contained in Section 3 of RFC 4962 [RFC4962].  This includes:
>    cryptographic algorithm independence; strong, fresh session keys;
>    replay detection; keying material confidentiality and integrity;
>    confirm cipher suite selection; and uniquely named keys.  In
>    addition, the tunnel method MUST support EAP channel bindings to
>    enable a system based on EAP to meet the additional requirements in
>    Section 3 of RFC 4962.
> 
> [SW] The reference to 4962 seems strange: that RFC does not 
> specify requirements on EAP types, but on AAA Key Management 
> Protocols. There is only few mentioning of EAP types in the 
> documents. All the requirements listed in this para are 
> mentioned in RFC4962 as desired properties of /AAA Key 
> Management Protocols/. Worse, RFC4962 states "However, an EAP 
> method MAY depend on a specific cryptographic algorithm.", 
> which is confusing to the requirements in this draft which 
> state otherwise. Suggest to delete para.
> 
[Joe] Some of the text may be redundant, but I'm not sure they are a problem.  We spent some time on this text so I would like to hear the opinion of the authors.

> 
> 4.2.1.4 Peer Id Privacy
> --------------------------------
> 
> This is already a MUST support due to the requirement of 
> unconditional compliance with RFC4017. So I wonder if this 
> needs to be re-iterated here.
> 
[Joe] I don't really see a problem with stating it, especially since it can be clarified somewhat. 

> 4.2.1.5 Session Resumption
> ---------------------------------------
> 
> Session Resumption is a "MUST support". It is certainly a 
> desirable property to lower needed re-auth round-trips, but I 
> don't see why it is crucial. I wonder if a SHOULD would do.
> 
[Joe] Well, if the method doesn't provide this I'm not sure people will really want to use it.  I agree its not critical to getting the job done, but I think its necessary to have a decent solution. 

> Greetings,
> 
> Stefan Winter
> 
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education 
> Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
> 
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 30 Oct 2008 17:35:23 -0700

> Sent: Tuesday, August 12, 2008 6:40 AM
> To: Josh Howlett
> Cc: [email-masked]
> Subject: Re: [Emu] Review of emu-eaptunnel-req-00, chunk 1
> 
> Hi,
> 
> > This is a desirable property IMHO. It's not unusual for 
> directories to 
> > employ policies that limit the use of credentials if they 
> are about to 
> > expire. If you can't log on to the network to change your 
> credentials 
> > so that you can log onto the network, you have a 
> chicken-and-egg situation.
> >
> > {EAP-}MSCHAP allows this, of course, so perhaps it doesn't 
> need to be 
> > a property of the outer-method providing that the 
> outer-method doesn't 
> > preclude the option.
> >   
> 
> The section in question states that the (outer) tunnel method 
> SHOULD provide support for it. Your reasoning is perfectly 
> fine for MS-CHAP in the *inner* auth. The outer method is not 
> supposed to interfere with the inner method's proceeding and 
> doesn't need to provide any special support.
> 
> The property of being able to change passwords within the 
> payload of the tunnel method is already expressed in section 
> 4.5.4 when it comes to dealing with legacy password databases 
> in the inner auth (where it belongs, IMHO). I'd suggest to 
> either mention it only in there, or to make sure in 3.1 that 
> any such management operation is not the tunnel method's "business".
> 
[Joe] OK I see your point.  We can clarify the it must support the inner exchange that supports passwords.

> > TLS is not itself a CPU intensive protocol, although some of the 
> > cipher suites are.
> >   
> 
> Point taken. That does not make the para in the document much 
> more useful though IMHO.
> 
> Greetings,
> 
> Stefan
> 
> --
> Stefan WINTER
> Ingenieur de Recherche

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 30 Oct 2008 17:56:03 -0700

Hi Again,

> Sent: Tuesday, August 12, 2008 6:45 AM
> To: [email-masked]
> Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 2 of 2
> 
> (continuing from 4.2.2 on)
> 
> 4.3 Tunnel payload reqs
> ----------------------------------
> 
> The criteria in this section seem to make it impossible to 
> use the described tunnel method as an inner payload itself 
> (i.e. prevents stacking of the method defined in this 
> document above each other). I'm not sure if there's a use 
> case for doing so, but seems like it's restricting where it 
> wouldn't need to be.
> 
[Joe] I'm not sure this would be desirable. 

> 4.5 Carrying U-N and PWs
> --------------------------------------
> 
> It is true that legacy dbs need the clear text password. They 
> don't always need to have it transmitted from the client 
> though (if they have it stored clear-text in the db, they can 
> do with a one-way hash from the client). The half-sentence 
> "hence they require the peer to send the clear text user name 
> and password to the EAP server" is wrong. The para reads as 
> if there is no way around sending the password in clear from 
> EAP peer to server.
> 
[Joe] So yes in some systems you either know what hash to send or ok can send a message telling the client that you need to salt with X and hash with y.  However, there are systems where you only have access to a verifier which takes the password as input and gives you a result.  This includes some OTP systems, but also includes systems based on static passwords.  So in these systems there is no way around it.  

> 4.5.1 Security
> -------------------
> Since the precondition in 4.5 above isn't true, the 
> introductory para needs to be re-worded. Maybe "Due to the 
> fact that some legacy password databases require the EAP peer 
> to send clear text passwords to enable the EAP server to 
> authenticate them, "
> 
[Joe] I disagree, this is true.  However, I agree that database may not be the right word here an may be the source of the issue.  We can change this to verifier.  

> 4.5.1.2 Auth of server
> ------------------------------
> section 3.5 specifies that the tunnel method MAY allow for a 
> bypass of server authentication. 4.5.1.2 forbids this bypass, 
> meaning the use case in 3.5 is badly catered by the tunnel 
> method specified in this document, if this tunnel method is 
> used in conjunction with legacy password databases. Maybe 
> this is worth mentioning?
> 
[Joe] Interesting,  This needs to be discussed. 

> 4.5.2 i18n
> --------------
> The MUST/SHOULD pair in the last sentence is already 
> specified as a tunnel payload req in general in 4.3.6 and 
> doesn't need to be repeated here.
> 
[Joe] I wouldn't assume that just because the tunnel supports i18n that the inner method does.  I think it would be worthwhile to keep this here. 

> 4.5.3 + 4.6.5 Meta-Data
> Meta-data is MUST in both of these sections (i.e. for 
> password-based auth and EAP auth), identical wording. To 
> avoid duplication, it might make sense to move this statement 
> into the general requirement section for tunneled payload (4.3).
> 
[Joe] Maybe, the meta data needs to be associated with the methods though... Need to think about this. 

> 6.1 Ciphersuite selection
> -----------------------------------
> The last para is a nice recitation on why mutually anonymous 
> tunnels are bad. It does not state the relation of this fact 
> to the requirements document though. Adding a sentence that 
> this risk has been taken care of by requiring server auth 
> would tie the paragraph into the document.
> 
[Joe]OK 

> 6.3 Outer EAP Method Header
> -------------------------------------------
> This section has good arguments why to protect the header of 
> the message exchange. Still, this is only a SHOULD in the 
> document. The para here suggests that it might better be a 
> MUST. What are the reasons for the SHOULD?
> 
[Joe] Yes some of this was discussed on a separate thread,  I think we should add text that is a MUST for data external to the tunnel that gives an attacker an advantage if they can modify it, this may not be the entire header.