eap Mailing List: IETF Last Call Issue 396: Another SecDir Review

[Bernard Aboba (bernard_aboba]

Issue 396: Another Secdir Review
Submitter name: David Harrington
Submitter email address: ietfdbh [at] comcast.net
Date Submitted:  February 23, 2007
Reference:
Document: KEYING-18
Comment type: Technical
Priority: S
Section: 1, 2
Rationale/Explanation of issue:

So far, I have only reviewed sections 1 and 2. I reviewed the document
for understandability, not just security considerations.

The single largest issue I have with this document is its use of
RFC2119 keywords, especially in lowercase. It is very difficult to
tell which specifications are required for interoperability, which
because the authors want to see a particular way of doing things, and
which are simply not requirements at all, but RFC2119 language is used
anyway. This point really needs work!

As I reviewed this document, I found sections that were not well
written, which could impact interpretation.
Some are obviously not security-related, e.g., spelling errors, but
others could affect security to varying degrees.
I think the document needs at least one more thorough revision to
tighten up the language.

<soap
This document covers a lot of ground, and will prove useful for
understanding how to bring these various efforts toegther for
consistent security. I thank the authors for doing this work.

I am concerned that this document is providing a retrospective of
existing practices. As co-chair of the syslog WG, where RFC3164
provides a retrospective of some well-known syslog implementations, I
am well aware that marketing departments everywhere LOVE
retrospectives documented in RFCs, so they can claim "compliance to
RFCxxxx". This document seems written the way RFC3164 was written - to
not offend anybody that had an existing specification.

I think this document would be much more useful if it set the bar
higher - if it actually set some standards to be met, and pointed out
where existing technologies fail to meet such a standard and should
probably be modified to improve interoperability and Internet
security, and suggested ways to migrate to more consistency between
specifications. Not easy politically, but the IETF is here to develop
standards, not to inadvertently bless existing non-interoperable
specifications.
</soap

Section 1.2.
KEK is not defined independent of the key wrap definiton.

Section 1.4
Paragraphs two and three are mostly duplicate text.
Note the difference between "may also store" and "also stores"

s/Initiatlization/Initialization/

It is unclear whether "required" and "may" are meant to be RFC2119
keywords.
I recommend that the terminology section describing RFC2119 also
explicitly mention whether lowercase keywords mean the same things.
There are LOTS of lowercase RFC2119 keywords throughout this document,
and this is very confusing. I recommend not using lowercase keywords
at all to prevent ambiguity.

"EAP methods also may export the IV; however, the use of the IV is
deprecated." Does this "may" mean "MAY" or "might"? If it means MAY,
then does that mean new EAP methods MAY export an IV?

"New EAP methods" is ambiguous. What defines "new"? If this means
anything defined after this document becomes an approved Proposed
Standard, then say that. If it means after a particular date that has
been set by the IESG, then say that. If it means newer than some
IANA-assigned method identifier, then say that.

What is a "null string"? I see that Appendix A mentions the use of an
empty string (zero length). Is this similar? It would be good to
clearly specify what a null string and/or emtpy string actually look
like. How are these encoded on the wire?

"Where an EAP method does not define a method-specific peer identity,
the Peer-Id is the null string." I find this ambiguous when combined
with the statement "New EAP method specifications MUST define the
Peer-Id, Server-Id and Session-Id." Does this mean that only for eap
methods defined prior to this document, the peer/server identity might
not be defined; therefore, it should be treated as having been defined
as being a null string? Or can new EAP methods define a Peer-Id and/or
Server-Id that is the null string?

Are "Where the EAP Type Code is less than 255," and "Where expanded
EAP Type Codes are used," mutually exclusive? That is, does "Where
expanded EAP Type Codes are used," imply that the EAP Type Code is
greater than or equal to 255? If so, this would be better written with
parallel construction. If they are not mutually exclusive, what
happens when they overlap?

1.4.1
"The scope of exported parameters is defined by the EAP Peer-Id (if
securely exchanged within the method) and the EAP
Server-Id (also only if securely exchanged)." I'm not quite sure
what 'defined" means in this context; does it mean the concatenation
of the two strings? How is scope defined if Peer-Id or Server-id is
NOT securely exchanged?

"Where a peer or server name is missing the null string is used." Does
"missing" include the case where the Peer-Id or Server-Id is not
securely exchanged? So if the Peer-Id is not securely exchanged, does
this mean the scope equals the securely exchanged Server-Id? And if
neither is securely exchanged, then the scope = the null string + the
null string = the null string?

I'm not sure I understand scope. What is a scope used for if both
Peer-Id and Server-Id have not been securely exhanged? A null string
identifying the parties to whom the key is available? i.e. it is not
available to anybody? If Peer-Id is securely exchznged, but not the
Server-Id, does this mean the scope is limited to the peer, and the
keys are only available to the peer?
If this is the concatenation of a nul string and a non-null string,
how do I tell Peer-Id+"" from ""+Server-Id?

"can be referred to"; does this qualify for RFC2119 language? how does
interoperability happen if binary or textual indications "can" be
used? Does this mean each method must specify which is the appropriate
format, or is it implementation-dependent?

"can be referred to ... Being referred to" is this redundant?

s/Secure Association protocol/Secure Association Protocol/

"The TEKs may or may not be named." and "The Transient Session Keys
(TSKs) are typically named." Consistency would improve readability;
either expand TEKs and TSKs (my preference) or don't expand either.

Section 1.5
"they are authorized to perform their roles either by each other" I
don't like "by each other" here. "themselves" would seem to work
better, or They are authorized to perform their roles, [and authorized
to delegate the performance of the roles to ...]

s/trusted to only transport EAP keying material to the
authenticator/trusted to transport EAP keying material to the
authenticator/ (the use of only makes the sentence difficult to parse
unambiguously - trusted to only transport? To transport only keying
material? What if there is additional material to transport? To
transport only to the authenticator? What if there are multiple
authenticators (with their own peers)? Can a AAA server only serve one
client?)

"trusted to refrain from" - is that a MUST refrain, a SHOULD refrain,
a MAY refrain? This paragraph would seem to benefit from having a
clear set of requirements for what a server MUST NOT do with the EAP
keying materials.

Section 1.6 Is the term "EAP Invariants" defined someplace? A
reference would help.

Section 1.6.4 "a specification MUST be provided" does not seem to be
consistent with RFC2119 usage guidelines

The sentence starting "Since ciphersuite negotiation" could use some
work. I had trouble parsing the sentence structure.

The "Advantages of ciphersuite-independence" are often written as the
disadvantages of not using ciphersuite independence, which really
isn't what is promised. For example "If EAP methods were to specify
how to derive transient session keys
for each ciphersuite, they would need to be updated each time a
new ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators, since
the backend authentication server would also need to be updated each
time support for a new ciphersuite is added to the authenticator." Is
this an advantage?
These "advantages" should be turned around to describe the advantages.

Section 2
s/keying material and material/keying material/

"The Initialization Vecor (IV) is deprecated." should probably say
"The Initialization Vecor (IV) is deprecated, but might be provided."

"MUST NOT be transported to another entity." - entity is not included
in the terminology section; another word choice might be better.

"The EAP layer as well as the peer and authenticator layers ..."
Aren't the peer and authenticator layer part of an EAP layer? I think
this needs better wording to show the context of the terminology.

Section 2.2. "Any of the authenticator architectures decribed in
[RFC4118] can be used." Does this mean ONLY architectures described in
RFC4118 can be used, or does this mean "For example, any of the ..."?

Section 2.2.1 "the keying material MUST be considered compromised."
Yeah, but then what? What standard of behavior should be followed in
response to the compromise? Should the EAP peer or backend server
immediately stop further communications with the presumably
compromised keying material? Just keep on working as if nothing
happened, knowing the material is compromised?


Figure 3 is in section 2.2.1, but is forward-referenced from section
2.2; why not put the figure in section 2.2 where it is first
referenced, so readers don't need to go looking backwards and forwards
in the document to find Figure 3?

"In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses."

Is this consistent with section 1.4.1?

"are always" does this mean "MUST be"?

(f) through (k) I recommend eliminating the "ing" and truning all
these incomplete clauses into sentences. That would seem much better
style since you also have sentences mixed into the bullets.

"Guest""virtual authenticator" - I think you can drop at least the
quote around virtual authenticator.

Section 2.2.2 has a list of steps to address the vulnerability of
virtual authenticators. It is unclear to me whether all these steps
must be undertaken simultaneously, or whether any one of the steps is
adequate to address the vulnerability, or how combinations of these
recommendations might work to address the vunerability.

The first step is ambiguous; I don't know how to interpret "apply
authorizations consistently". Given the example from above, does this
mean the authenticator should **consistently** let a peer authorized
as Guest have access to the corporate intranet?
How does caching the authorizations and keing material ensure that an
attacker cannot obtain elevated access? I don't see the relationship
between the action and the claimed result. Is the authenticator
expected to **do something** with the cached information?

Why is the first step REQUIRED, but all the other steps only
RECOMMENDED? Why not required? What circumstances would justify NOT
doing these steps? Can I do step one and ignore all the other steps?
If so, why bother to mention them?

" EAP methods that support mutual authentication may not allow the
EAP peer to verify the EAP server identity."
Is this "MAY NOT" or "might not"?

Section 2.3 tends to paint a doomsday picture - all these things can
go wrong. Can you make some recommendations for how to avoid having
these things go wrong? How SHOULD or COULD server identification be
handled to avoid these problems? Ya gotta ac-centuate the positive,
eliminate the negative ;-)

A stylistic point. Throughout this document, you reference a
tremendous number of RFCs. It could be helpful if you used mnemonic
citations like [RADIUS} rather than [RFCxxx], at least for th emost
common citations. I had to keep the multi-page reference section handy
as a rosetta stone to understand what you were citing, which hurt my
ability to read and understand the content.

Hope this helps; I plan to continue through more of the document next
week.