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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
