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

From: Stefan Winter <[email-masked]>
Date: Fri, 08 Aug 2008 16:09:49 +0200

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.

1. Introduction
----------------

The second sentence misses a reference behind 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?

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... ?

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.

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.

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.

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.

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.

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

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 8 Aug 2008 15:42:09 +0100

Hi Stefan,

> "support for minimal management tasks including password 
> change". I fail to see why a management mechanism to *change* 
> the password is needed

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 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.

TLS is not itself a CPU intensive protocol, although some of the cipher
suites are. 

best regards, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Stefan Winter <[email-masked]>
Date: Tue, 12 Aug 2008 15:40:02 +0200

Hi,

> property of the outer-method providing that the outer-method doesn't

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".

> TLS is not itself a CPU intensive protocol, although some of the cipher

Point taken. That does not make the para in the document much more 
useful though IMHO.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Tue, 12 Aug 2008 15:44:38 +0200

(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.

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.

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, "

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?

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.

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).

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.

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?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473