| Re: SecDir review, part 1: draft-ietf-eap-keying-18.txt | <– Date –> <– Thread –> |
From: Bernard Aboba (bernard_aboba hotmail.com)
|
|
| Date: Sat, 5 May 2007 11:20:08 -0700 (PDT) | |
Thanks for your review. Comments below.
==================
From: "David Harrington" <ietfdbh [at] comcast.net
To: <secdir [at] mit.edu, "'Sam Hartman'" <hartmans-ietf [at] mit.edu,
<housley [at] vigilsec.com
CC: pasi.eronen [at] nokia.com, dansimon [at] microsoft.com, bernarda [at]
microsoft.com,
"'Henrik Levkowetz'" <henrik [at] levkowetz.com
Subject: [secdir] SecDir review, part 1: draft-ietf-eap-keying-18.txt
Date: Fri, 23 Feb 2007 19:35:55 -0500I have partially reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.
Document: draft-ietf-eap-keying-18
Title: EAP Key Management Framework
Technical Summary:
This document specifies the EAP key hierarchy and provides a
framework for the transport and usage of keying material generated by EAP
authentication algorithms, known as "methods". It also provides a
system-level security analysis.
Review
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
[BA] Given the IETF process, compromises are inevitable. However, there are quite a few security recommendations in the document that seek to improve established practices, so that I wouldn't say that the document endorses existing practice in a blanket way.
Section 1.2. KEK is not defined independent of the key wrap definiton.
[BA] The term KEK is only used in the context of key wrap.
Section 1.4 Paragraphs two and three are mostly duplicate text.
[BA] Tim Polk's DISCUSS comment has resulted in paragraph two being removed.
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.
[BA] I have gone over the usage of the terms "may", "may not", "should", "should not", "required" and "must" within the document. In the vast majority of cases, the usage appears to be non-normative, but there are a few cases where it does appear that there is normative intent. These are flagged below. To make sure there is no confusion, I have tried to eliminate the use of these lower case words by replacing "may" with "can", "required" with "needed", and "may not" with "it is possible that... will not".
"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?
[BA] It does mean "MAY" here, I believe.
"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.
[BA] The intent here was to mean "EAP methods published after approval of this specification".
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?
[BA] I have changed "empty string" to "null string" everywhere. In general, AAA protocols such as RADIUS do not encode "null strings" over the wire; instead, no attribute is sent.
"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?
[BA] New EAP methods can define a Server-Id that is the null string; however, methods that do mutual authentication and key derivation will typically define a Peer-Id.
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?
[BA] They are mutually exclusive; the language has been changed to reflect this.
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?
[BA] I have change the language to make this more clear (see below).
"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?
[BA] RFC 3748 mandates that methods which derive keys do mutual authentication. Also, it is recommended that methods have their own method-specific identity exchanges. Methods heeding this advice will define a Peer-Id, but perhaps not a Server-Id.
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?
[BA] I have added a clarification that methods deriving keys SHOULD provide a Peer-Id, so as to clarify the key scope.
"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?
[BA] this is not RFC 2119 language. Interoperability is achieved by specifying the name encoding within the AAA attribute specification. For example, in RFC 4072, the EAP-Key-Name attribute is defined, which contains the Session-Id. The type of key is implied by the name of additional attributes included in the message (e.g. EAP-Master-Session-Key AVP).
"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.
[BA] Fixed.
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 ...]
[BA] This text came from "AAA Key Management Guidelines" and is just quoted here. To clarify this, I have added explicit references within the requirements.
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.
[BA] This text also comes from AAA Key Management Guidelines. I believe it is non-normative.
Section 1.6 Is the term "EAP Invariants" defined someplace? A reference would help.
[BA] See changes below.
Section 1.6.4 "a specification MUST be provided" does not seem to be consistent with RFC2119 usage guidelines
[BA] I've removed the MUST.
The sentence starting "Since ciphersuite negotiation" could use some work. I had trouble parsing the sentence structure.
[BA] See changes below.
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.[BA] Done.
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."
[BA] Fixed.
"MUST NOT be transported to another entity." - entity is not included in the terminology section; another word choice might be better.
[BA] AAA Key Management Guidelines uses the term "party", but I think they're roughly equivalent.
"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.
[BA] RFC 3748 defines EAP layering; the peer and authenticator layers are distinct from the EAP or method layers.
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 ..."?
[BA] Have changed the text to "For example, any..."
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?
[BA] What happens next depends on the lower layer. Within WPA, if a compromise is detected, communication is shut down completely. In other cases, it might make more sense for the peer to log the problem or move to another authenticator.
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?
[BA] Fixed.
"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?
[BA] I believe it is consistent.
"are always" does this mean "MUST be"?
[BA] If the two parties were not co-resident, then channel bindings would fail. So I believe it is equivalent to "MUST", yes.
(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.
[BA] Fixed.
"Guest""virtual authenticator" - I think you can drop at least the quote around virtual authenticator.
[BA] Quotes have been removed everywhere, as well as for "virtual peer".
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.
[BA] I have clarified the text. The measures can be taken in any combination.
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?
[BA] I have clarified the text. The intent here was that authorizations would be applied on each access.
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?
[BA] The other steps are not required because if the first step is taken, then vulnerabilities only exist in some circumstances that may not be common.
" 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"?
[BA] I have added text to clarify the obligations.
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 ;-)
[BA] The issues can be addressed by deploying EAP methods which export the Server-Id.
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 the most 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.
David Harrington dharrington [at] huawei.com dbharrington [at] comcast.net ietfdbh [at] comcast.net
========================================= Proposed changes (from diff):
< Part of this keying material may be used by EAP methods
< themselves and part of this material may be exported.
< In addition to export of keying material, EAP methods may also export associated
---
Part of this keying material can be used by EAP methods143c143
themselves and part of this material can be exported. In addition to export of keying material, EAP methods can also export associated
< EAP conversation identifier, and may import and export lower layer parameters known
---
EAP conversation identifier, and import and export lower layer parameters known
181,182c181,182 < The term AAA-Key is synonymous with MSK. Since multiple keys < may be transported by AAA, the term is potentially confusing ---
The term AAA-Key is synonymous with Master Session Key (MSK). Since multiple keys
can be transported by AAA, the term is potentially confusing
229c229 < has been deprecated and EAP methods are not required to generate ---
has been deprecated and it is OPTIONAL for EAP methods to generate
233c233 < .IP "Keywrap" ---
.IP "Key Wrap"
272c272 < Elements of a security association may include cryptographic keys, ---
Elements of a security association include cryptographic keys,
285,286c285,286
< A peer may ---
A peer can
331c331 < network, or a peer may locate an authenticator ---
network, or a peer can locate an authenticator
337c337 < The authentication phase (phase 1) may begin once the ---
The authentication phase (phase 1) can begin once the
344c344 < An additional step (phase 1b) is required in deployments which ---
An additional step (phase 1b) is needed in deployments which348,349c348,349
< server is present, all keying material which is required by the lower layer needs to
< be transported from the EAP server to the authenticator.
---
server is present, all keying material needed by the lower layer is transported from the EAP server to the authenticator.
419c419
< two 4-way handshakes may be required in order to support ---
two 4-way handshakes can be needed in order to support465,466c465,466
< information is typically used outside of the EAP method to determine if access to
< some service should be granted.
---
information is typically used outside of the EAP method to determine whether to grant access to a service.474,481d473
< The EAP server may also store additional
< information associated with the peer's identity and the peer stores
< information necessary to choose which certificate to use for which service.
<
< If authentication is based on proof of possession of the private key
< corresponding to the public key contained within a certificate, the
< parties store the EAP method to be used and the trust anchors used to
< validate the certificates.
492c484
< (MSK), Extended Master Session Key (EMSK), Initiatlization
---
(MSK), Extended Master Session Key (EMSK), Initialization
496,500c488
< As noted in [RFC3748] Section 7.10, EAP methods generating keys are < required to calculate and export the MSK and EMSK, which must be at < least 64 octets in length. < EAP methods also may export the IV; < however, the use of the IV is deprecated. ---
As noted in [RFC3748] Section 7.10:501a490,499
508,510c506,509.in +0.3i In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. .in -0.3i
EAP methods also MAY export the IV; however, the use of the IV is deprecated.
< EAP methods also MAY export method-specific peer (Peer-Id) and server (Server-Id)
< identifiers and a method-specific EAP
< conversation identifier known as the Session-Id.
---
EAP methods supporting key derivation and mutual authentication SHOULD export
a method-specific EAP conversation identifier known as the Session-Id, as well as a peer identifier (Peer-Id) and MAY export a method-specific server identifier (Server-Id).
512c511,512 < New EAP method specifications MUST define the Peer-Id, Server-Id and ---
EAP method specifications developed after the publication of this document MUST define the Peer-Id, Server-Id and
524c524 < the EAP-Response/Identity may be different from the peer identity ---
the EAP-Response/Identity can be different from the peer identities
526c526 < provided in the EAP-Response/Identity may be a privacy identifier ---
provided in the EAP-Response/Identity can be a privacy identifier
528c528 < or may be decorated as ---
or can be decorated as
531,534c531,536
< authenticates the peer identity, that identity is exported by the < method as the Peer-Id. A suitable EAP peer name may not always be < available. Where an EAP method does not define a method-specific < peer identity, the Peer-Id is the null string. ---
authenticates one or more peer identities, those identities are exported by the
method as the Peer-Id(s). It is possible for more than one Peer-Id to be exported
by an EAP method. For example, in a tunneling method, more than one
peer identity can be authenticated. Not all EAP methods provide a method-specific peer identity; where this is not
defined, the Peer-Id is the null string.
540,545c542,547 < Where the EAP method authenticates the server identity, that < identity is exported by the method as the Server-Id. < A suitable EAP server name may not always be available. < Where an EAP method < does not define a method-specific server identity, the Server-Id is < the null string. ---
Where the EAP method authenticates one or more server identities, those
identities are exported by the method as the Server-Id(s). It is
possible for more than one Server-Id to be exported by an EAP method,
such as within a tunneling method. Not all EAP methods provide a server identity; where this is not defined,
the Server-Id is the null string.
575,576c577,578
< Where the EAP Type Code is less than 255, < the EAP Session-Id consists of the concatenation < of the EAP Type Code and a temporally unique identifier obtained ---
Where non-expanded EAP Type Codes are used (EAP Type Code not
equal to 254),
the EAP Session-Id is the concatenation
of the single octet EAP Type Code and a temporally unique identifier obtained
599c602 < This unique identifier is typically constructed from nonces or counters ---
The Method-Id is typically constructed from nonces or counters
601c604
< The inclusion of the Type Code ---
The inclusion of the Type Code or Expanded Type Code
628,631c631,638 < 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). < Where a peer or server name is missing the null string is used. ---
The scope of exported parameters is defined by the authenticated peer identities (Peer-Id(s)) and the authenticated server identities (Server-Id(s)), where available. Where an EAP method that derives keys does not provide a Server-Id, the EAP peer will not know the identity of the EAP server with which it derived EAP keying material. Where an EAP method that derives keys does not provide a Peer-Id, the EAP server will not know the identity of the EAP peer with which it derived EAP keying material.
633,634c640,642 < These parameters are exported by the EAP peer and EAP server, and can < be referred to using the EAP Session-Id and a binary or textual ---
These parameters are exported by the EAP peer and EAP server, and MUST be named using the EAP Session-Id and a binary or textual641c649
< to refer to it in the Secure Association protocol; the PMK name (known as the PMKID) is
---
to refer to it in the Secure Association Protocol; the PMK name (known as the PMKID) is
645,647c653,655 < The TEKs may or may not be named. < Their naming is specified in the < EAP method. ---
Transient EAP Keys (TEKs) MAY be named; their naming is specified in the EAP method specification.
649c657 < The Transient Session Keys (TSKs) are typically named. ---
Transient Session Keys (TSKs) are typically named.
670c678
< and the authenticator must locally implement an EAP method < acceptable to the peer. ---
and the authenticator locally implements one or more EAP methods.
746c753 < While the authenticator may implement some EAP ---
While the authenticator can implement some EAP
748c755 < may at the same time act as a pass-through for other users and ---
can at the same time act as a pass-through for other users and
768,769c775,776 < Even though the EAP peer or server may < import channel binding parameters that may include the identity ---
Even though the EAP peer or server can import channel binding parameters that can include the identity
778c785 < the principle of mode independence, so that as far as the EAP peer is ---
the principle of mode independence. As far as the EAP peer is
800c807 < Note that media independence may be retained within EAP methods that ---
Note that media independence can be retained within EAP methods that
816,817c823,824 < methods. This allows the authenticator to avoid implementing code < for each EAP method required by peers. ---
methods. This allows the authenticator to avoid having to implement the EAP methods configured for use by peers.
819c826 < authenticator is not required to implement any EAP methods at all, it ---
authenticator need not implement any EAP methods at all, it
820a828,833
As noted in [RFC3748] Section 2.3:
.in +0.3i
Compliant pass-through authenticator implementations MUST by default forward EAP
packets of any Type.
.in -0.3i
822,823d834 < As a result, as noted in [RFC3748], authenticators must by default be < capable of supporting any EAP method. 830,831c841,842 < derivation, and as a result is not appropriate for use in wireless < LAN authentication [RFC4017]. ---
derivation, and as a result is not appropriate for use in Wireless Local Area Network (WLAN) authentication [RFC4017].
834c845 < EAP method is supported on the EAP server. ---
EAP method is supported both on the EAP peer and server.841c852,853
< Ciphersuite Independence is a requirement for Media Independence. Since lower
---
Ciphersuite Independence is a requirement for Media Independence. Since lower
846c858 < While EAP methods may negotiate the ciphersuite used in protection of ---
While EAP methods can negotiate the ciphersuite used in protection of
861c873 < layer, requiring EAP methods have knowledge of lower layer ---
layer, requiring that EAP methods have knowledge of lower layer862a875
As a result, EAP methods generate keying material that is ciphersuite-independent.864,865c877
< need for lower layer ciphersuite negotiation within EAP, and EAP methods generate
< keying material that is ciphersuite-independent.
---
need for lower layer ciphersuite negotiation within EAP.
868c880 < framework, a specification MUST be provided describing how TSKs ---
framework, the ciphersuite specification needs to describe how TSKs877a890,891
Ciphersuite independence enables EAP methods to be used with new ciphersuites without requiring the methods to be updated.
886a901,902
890a907,909Ciphersuite independence enables EAP methods to avoid having to include ciphersuite-specific code.
Ciphersuite independence enables EAP method implementations on the peer and server to avoid
having to configure ciphersuite-specific parameters.
896c915 < As a result, the EAP server may not have knowledge of the ---
As a result, the EAP server does not have knowledge of the
898c917 < authenticator, or be aware of the ciphersuite negotiated between ---
authenticator, nor is it aware of the ciphersuite negotiated between
900,901c919,920 < For example, since ECP negotiation occurs after authentication, < when run over PPP, the EAP peer and server may not anticipate ---
For example, since Encryption Control Protocol (ECP) negotiation occurs after authentication,
when run over PPP, the EAP peer and server cannot anticipate
911c930 < material and parameters exported by the EAP method are provided ---
parameters exported by the EAP method are provided
915c934 < Peer-Id, Server-Id and Session-Id. ---
Peer-Id(s), Server-Id(s) and Session-Id.
917c936 < Vector (IV) is deprecated. ---
Vector (IV) is deprecated, but might be provided.
937c956 < the AAA layer may be replicated to the AAA layer on the ---
the AAA layer MAY be replicated to the AAA layer on the
1025c1044 < Existing implementations of RADIUS/EAP [RFC3579] or Diameter ---
Existing implementations and specifications for RADIUS/EAP [RFC3579] or Diameter
1048c1067 < Any of the authenticator architectures described ---
For example, any of the authenticator architectures described
1061c1080
< It should be understood that an EAP authenticator or peer: ---
An EAP authenticator or peer:
1064,1065c1083,1084 < (a) may contain one or more physical or logical ports; < (b) may advertise itself as one or more "virtual" ---
(a) can contain one or more physical or logical ports; (b) can advertise itself as one or more "virtual"
1067,1068c1086,1087 < (c) may utilize multiple CPUs; < (d) may support clustering services for load balancing or failover. ---
(c) can utilize multiple CPUs; (d) can support clustering services for load balancing or failover.1071c1090
< Both the EAP peer and authenticator may have more than one physical or logical
---
Both the EAP peer and authenticator can have more than one physical or logical
1073c1092 < A peer may simultaneously access the network via multiple ---
A peer can simultaneously access the network via multiple
1075c1094 < Similarly, an authenticator may offer network access to multiple peers, ---
Similarly, an authenticator can offer network access to multiple peers,
1079,1080c1098,1099 < "virtual authenticators", it is possible for a single physical port < to belong to multiple "virtual authenticators". ---
virtual authenticators, it is possible for a single physical port to belong to multiple virtual authenticators.
1082c1101 < An authenticator may be configured to communicate with more than one ---
An authenticator can be configured to communicate with more than one
1086,1111d1104 < Since an authenticator may have multiple ports, the scope of the < authenticator key cache may not be described by a single endpoint ---
Since an authenticator can have multiple ports, the scope of the authenticator key cache cannot be described by a single endpoint
1165c1181 < Similarly, where a peer may have multiple ports and ---
Similarly, where a peer can have multiple ports and
1176c1192 < authenticator and AAA client are always co-resident, this mechanism ---
authenticator and AAA client MUST be co-resident, this mechanism
1182c1198 < Since a NAS may have more than one IP address, the ---
Since a NAS can have more than one IP address, the
1187c1203 < Problems which may arise where the peer and ---
Problems which can arise where the peer and
1191c1207,1208 < It may not be obvious to the peer which authenticator ports are ---
It is possible that the peer will not be able to determine which authenticator ports are
1193c1210,1211 < The EAP peer will ---
As a result, the EAP peer will be unable to utilize the authenticator key cache in an efficient way, and will also
1195,1197c1213 < outside its authorized scope, and needs to be considered compromised. < The EAP peer may also be unable to utilize the authenticator < key cache in an efficient way. ---
outside its authorized scope, and therefore needs to be considered compromised.
1199,1202c1215,1218 < It may not be obvious to the authenticator which peer ports are < associated with which peers. < As a result, the authenticator may < not be able to enable a peer to communicate with it utilizing ---
It is possible that the authenticator will not be able to determine which peer ports are associated with which peers, preventing the peer from communicating with it utilizing
1205c1221,1222 < It may not be obvious to the peer which "virtual authenticator" it ---
It is possible that the peer will not be able to determine which virtual authenticator it
1207,1210c1224,1227 < For example, multiple "virtual authenticators" < may share a MAC address, but utilize different NAS-Identifiers. < .IP (d) < It may not be obvious to the authenticator which "virtual peer" it ---
For example, multiple virtual authenticators
can share a MAC address, but utilize different NAS-Identifiers. .IP (d)
It is possible that the authenticator will not be able to determine which virtual peer it
1212c1229 < Multiple "virtual peers" may share ---
Multiple virtual peers can share
1215,1216c1232,1233 < It may not be possible for the EAP peer and server to verify the < authenticator identity via Channel Binding. ---
It is possible that the EAP peer and server will not be able to verify the authenticator identity via Channel Binding.
1222c1239 < peer to utilize a single port. ---
virtual peer to utilize a single port.
1227c1244 < Specifying the lower layer parameters used to identify the ---
Specify the lower layer parameters used to identify the
1234c1251 < Communicating the lower layer identities between the peer and ---
Communicate the lower layer identities between the peer and
1240c1257 < Communicating the lower layer authenticator identity between the ---
Communicate the lower layer authenticator identity between the
1244c1261 < Including the lower layer identities within Channel Bindings (if ---
Include the lower layer identities within Channel Bindings (if
1248c1265 < Supporting the integrity-protected exchange of identities within ---
Support the integrity-protected exchange of identities within
1251c1268 < Utilizing the advertised lower layer identities to enable the peer ---
Utilize the advertised lower layer identities to enable the peer
1261c1278 < "virtual authenticators", if the virtual authenticators do not maintain ---
virtual authenticators, if the virtual authenticators do not maintain
1268c1285 < could authenticate with the "Guest" "virtual authenticator" and derive ---
could authenticate with the "Guest" virtual authenticator and derive
1275c1292 < In order to address this vulnerability: ---
The following steps can be taken to mitigate this vulnerability:
1279c1296,1297 < authorizations consistently. ---
authorizations to the peer on each network access, regardless of which virtual authenticator is being accessed.
1281c1299,1301 < where the key cache is shared between "virtual authenticators". ---
where the key cache is shared between virtual authenticators, and a peer obtains access to one virtual authenticator utilizing a key cache entry created for use with another virtual authenticator.
1285c1305,1316 < "virtual authenticator". ---
virtual authenticator. This ensures that a cache entry created for use with one virtual authenticator cannot be used for access to another virtual authenticator. Since a key cache entry can no longer be shared between virtual authentications, this step provides protection beyond that offered in (a). This is valuable in situations where authorizations are not used to enforce access limitations. For example, where access is limited using a filter installed on a router rather than using authorizations provided to the authenticator, a peer can gain unauthorized access to resources by exploiting a shared key cache entry.
1287c1318 < It is RECOMMENDED that each "virtual authenticator" identify itself ---
It is RECOMMENDED that each virtual authenticator identify itself
1290c1321 < Channel Binding (see Section 5.3.3). ---
Channel Binding (see Section 5.3.3).
1292c1323 < It is RECOMMENDED that each "virtual authenticator" identify itself ---
It is RECOMMENDED that each virtual authenticator identify itself
1306,1307c1337,1338 < authenticator may be configured to communicate with multiple EAP < servers; the EAP server that an authenticator communicates with may ---
authenticator can be configured to communicate with multiple EAP servers; the EAP server that an authenticator communicates with can
1313c1344 < Authenticators may be configured with different primary ---
Authenticators can be configured with different primary
1318c1349 < authenticator may fail over to another EAP server. ---
authenticator can fail over to another EAP server.
1320c1351 < Authenticator2 may be initially configured with EAP server1 as its ---
Authenticator2 can be initially configured with EAP server1 as its
1322c1353 < but if EAP server1 becomes unavailable, EAP server2 may become the ---
but if EAP server1 becomes unavailable, EAP server2 can become the
1335,1336c1366,1367 < EAP methods may or may not export the Server-Id, and < as a result, the EAP peer may not even learn which server ---
Some EAP methods do not export the Server-Id so that is is possible that the EAP peer will not learn which server
1341c1372 < reconnecting to the same authenticator, may find itself communicating ---
reconnecting to the same authenticator, can find itself communicating
1343c1374 < Fast reconnect, defined in [RFC3748] Section 7.2, may fail if ---
Fast reconnect, defined in [RFC3748] Section 7.2, can fail if1347c1378
< session resume may find that the new EAP-TLS server will not have access to the TLS Master
---
session resume can find that the new EAP-TLS server will not have access to the TLS Master1351,1355c1382,1388
< EAP methods that support mutual authentication
< may not allow the EAP peer to verify the EAP server identity.
< For example, the EAP peer
< may only verify that the EAP server possesses a long-term secret; in this case the EAP
< peer will only know that an authenticator has been authorized by an EAP server, but will
---
Not all EAP methods that support mutual authentication allow the EAP peer to verify the EAP server identity. For example, in some cases the EAP peer can only verify that the EAP server possesses a long-term secret; in this case the EAP peer will only know that an authenticator has been authorized by an EAP server, but will
1360c1393 < EAP methods exporting the Server-Id determine this from the ---
EAP methods exporting the Server-Id typically determine this from the1366c1399
< Validating the EAP server identity may help the EAP peer to decide whether a
---
Validating the EAP server identity can help the EAP peer to decide whether a1370c1403
< in the server certificate, it may even be possible for the peer to verify some Channel Binding
---
in the server certificate, it can even be possible for the peer to verify some Channel Binding1380c1413
< by EAP methods may not be identical to the Fully Qualified Domain Name (FQDN) of the
---
by EAP methods MAY NOT be identical to the Fully Qualified Domain Name (FQDN) of the
1384,1385c1417,1418 < subjectAltName used in the backend server certificate may < not be identical to the Server-Id or backend server FQDN. ---
subjectAltName used in the backend server certificate MAY NOT be identical to the Server-Id or backend server FQDN.
1388c1421 < in the certificate, the AAA client may not be able to successfully ---
in the certificate, it is possible that the AAA client will not be able to
1391c1424 < Where the Server-Id and backend server FQDN differ, the ---
Where the Server-Id and backend server FQDN differ, it is possible that the1393c1426
< (Session-Id) may not be sufficient for the authenticator to determine where the
---
(Session-Id) will not be sufficient for the authenticator to determine where the
1395c1428 < For example, the authenticator may identify ---
For example, the authenticator can identify
1422c1455 < protected may have lower layer source and destination addresses different ---
protected can have lower layer source and destination addresses different
1427c1460 < although EAP methods may support "fast reconnect" as defined in ---
although EAP methods can support "fast reconnect" as defined in
1491c1524 < Where key caching is supported, it may be possible for the EAP peer ---
Where key caching is supported, it is possible for the EAP peer
1512c1545 < the EAP peer lower layer may initiate a ---
the EAP peer lower layer can initiate a
1514c1547 < session. Were the TSKs to be derived from a portion of the ---
session. Were the TSKs to be derived only from a portion of the
1536c1569 < may handle re-key and determination of the key lifetime. Where ---
MAY handle re-key and determination of the key lifetime. Where
1539c1572 < Lower layers that support re-key, but not key caching, may not require ---
Lower layers that support re-key, but not key caching, MAY NOT require
1553c1586 < key cache will remain synchronized, and the peer may not ---
key cache will remain synchronized, and it is possible that the peer will not
1560c1593 < resynchronization exchange, securing this mechanism may be ---
resynchronization exchange, securing this mechanism can be
1575c1608 < may not necessarily have the same lower layer source or destination ---
will not necessarily have the same lower layer source or destination1586c1619
< Station (SS) may forward traffic to the Base Station (BS) which originates
---
Station (SS) can forward traffic to the Base Station (BS) which originates
1591c1624 < In both IKEv2 and IEEE 802.16e, multiple security associations may ---
In both IKEv2 and IEEE 802.16e, multiple security associations can
1642c1675 < For example, in 802.11, the backend authentication server may ---
For example, in IEEE 802.11, the backend authentication server can
1699c1732 < However, methods may ---
However, methods can
1708c1741,1742 < despite TEK re-keying or caching. This prevents TEK compromise from ---
despite TEK re-keying or caching. This prevents TEK compromise from
1711c1745 < EAP methods may cache local keying material which may persist ---
EAP methods MAY cache local keying material which can persist
1725,1726c1759,1760 < card hold holding the private key for EAP-TLS may have < been removed. EAP servers SHOULD also verify that the ---
smartcard holding the private key for EAP-TLS can have been removed. EAP servers SHOULD also verify that the
1750c1784 < is not provided by the lower layer, there may be no way for the ---
is not provided by the lower layer, it is possible that there will not be a way for the
1781c1815 < exported keying material may also persist that material after ---
exported keying material MAY also persist that material after
1784c1818 < situations it may be desirable for the backend authentication ---
situations it can be desirable for the backend authentication
1807,1808c1841,1842 < future additional attributes may be specified to control < the lifetime of cached keys; these attributes may modify the ---
future additional attributes can be specified to control the lifetime of cached keys; these attributes MAY modify the
1840,1842c1874,1886 < All EAP methods generating keys are required to generate the MSK and < EMSK, and may optionally generate the IV. However, EAP, defined in < [RFC3748], does not itself support the negotiation of lifetimes for ---
As noted in [RFC3748] Section 7.10:
.in +0.3i In order to provide keying material for use in a subsequently negotiated ciphersuite, an EAP method supporting key derivation MUST export a Master Session Key (MSK) of at least 64 octets, and an Extended Master Session Key (EMSK) of at least 64 octets. EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server. .in -0.3i
However, EAP does not itself support the negotiation of lifetimes for
1867c1911 < The lower layer may utilize the Discovery phase 0 to improve key ---
The lower layer can utilize the Discovery phase 0 to improve key
1892c1936,1937 < of attack resistance. This is typically provided by ---
of attack resistance. This is typically provided by1933a1979
A handoff occurs when an EAP peer moves to a new authenticator.
1953c1999 < As a result, EAP (phase 1a) is not required, but the ---
As a result, EAP (phase 1a) is not needed, but the
1965c2011 < are still required. ---
are still needed.
1976c2022 < it is still required, although it may be shortened. ---
it is still needed, although it can be shortened.1986c2032
< Secure Association Protocol exchanges (phase 2) still occur, although the latter may be shortened.
---
Secure Association Protocol exchanges (phase 2) still occur, although the latter can be shortened.
1990c2036 < still required, although it may be shortened. ---
still needed, although it can be shortened.2021,2022c2067,2068
< material, then peer may not be able to complete EAP pre-authentication prior to
< connectivity loss or may pre-authenticate multiple times with the same authenticator,
---
material, then it is possible that the peer will not be able to complete EAP pre-authentication prior to2025,2028c2071,2074
connectivity loss or that it can pre-authenticate multiple times with the same authenticator,
< Since a peer may complete EAP pre-authentication with an authenticator without eventually
< attaching to it, phase 2 may never occur.
< As a result, an Accounting-Request signifying the start of service may
< never be sent, or may only be sent with a substantial delay after the
---
Since a peer can complete EAP pre-authentication with an authenticator without eventually
attaching to it, it is possible that phase 2 will not occur. In this case
an Accounting-Request signifying the start of service will
not be sent, or will only be sent with a substantial delay after the
2044,2045c2090,2091 < EAP authentication attempt, the backend < authentication server may not be able to determine whether a ---
EAP authentication attempt, it is possible that the backend authentication server will not be able to determine whether a
2049,2050c2095,2096 < sessions is limited, the backend authentication server may < refuse to authorize a valid EAP pre-authentication attempt or may enable ---
2054c2100sessions is limited, the backend authentication server can refuse to authorize a valid EAP pre-authentication attempt or can enable
< never attaches to, the backend accounting server may not be able to determine
---
never attaches to, it is possible that the backend accounting server will not be able to determine2076c2122
< authenticator, then the previous authenticator may potentially know the session
---
authenticator, then the previous authenticator can potentially know the session2160c2203
< may potentially know the session keys used between the peer and the previous
---
can potentially know the session keys used between the peer and the previous
2178c2221 < the user may also provide authorization information. ---
the user can also provide authorization information.
2191,2192c2234,2235 < Are there any fraud, credit limit, or other concerns indicating < that access should be denied? ---
Are there any fraud, credit limit, or other concerns that could lead to access denial?
2199c2242 < the distributed decision making process may add complexity. ---
the distributed decision making process can add complexity.2212c2255
< service parameters or constraints may be communicated to the authenticator.
---
service parameters or constraints can be communicated to the authenticator.
2233c2276 < should not enable a user to extend their network access or gain access to ---
SHOULD NOT enable a user to extend their network access or gain access to
2236c2279 < Handoff techniques should not ---
Handoff techniques SHOULD NOT2239c2282
< For example, a backend authentication server may need to keep track of simultaneous
---
For example, a backend authentication server can need to keep track of simultaneous
2301c2344 < Although it may seem somewhat counter-intuitive, failure is indeed ---
Although it can seem somewhat counter-intuitive, failure is indeed2318c2361
< the backend authentication server may return different authorizations depending on the
---
the backend authentication server can return different authorizations depending on the2340,2341c2383,2384
< Similarly, a handoff between an authenticator providing confidentiality and another that does not
< should fail, since if the handoff were successful,
---
Similarly, it is preferrable for a handoff between an authenticator providing confidentiality and another that does not
to fail, since if the handoff were successful,
2367c2410 < The attacker may be a principal or an outsider. ---
The attacker can be a principal or an outsider.
2373c2416 < An attacker may compromise or steal an EAP peer or authenticator, ---
An attacker can compromise or steal an EAP peer or authenticator,
2377c2420 < An attacker may attempt a downgrade attack in order to exploit ---
An attacker can attempt a downgrade attack in order to exploit
2381c2424 < An attacker may try to modify or spoof packets, including ---
An attacker can try to modify or spoof packets, including
2385c2428 < An attacker may attempt to induce an EAP peer, authenticator ---
An attacker can attempt to induce an EAP peer, authenticator
2390c2433 < An attacker may alter, forge or replay packets. ---
An attacker can alter, forge or replay packets.
2392,2393c2435,2436 < An attacker may cause an EAP peer, authenticator or < server to reuse a stale key. Use of stale keys may also ---
2395,2396c2438,2439An attacker can cause an EAP peer, authenticator or server to reuse a stale key. Use of stale keys can also
< backend authentication server may provide stale keying material to an authenticator,
< or a poorly implemented authenticator may reuse nonces.
---
backend authentication server can provide stale keying material to an authenticator,
or a poorly implemented authenticator can reuse nonces.
2398c2441 < An authenticated attacker may attempt to obtain elevated privilege ---
An authenticated attacker can attempt to obtain elevated privilege
2401c2444 < An attacker may attempt a man-in-the-middle attack in order to gain access ---
An attacker can attempt a man-in-the-middle attack in order to gain access
2404c2447 < An attacker may compromise an EAP authenticator in an effort ---
An attacker can compromise an EAP authenticator in an effort
2406c2449 < may provide incorrect information to the EAP peer and/or ---
can provide incorrect information to the EAP peer and/or
2412c2455 < An attacker may launch a denial of service attack against the EAP ---
An attacker can launch a denial of service attack against the EAP
2427,2428c2470,2471 < an attacker may gain access to the network through that authenticator, < or may obtain the credentials required for the ---
an attacker can gain access to the network through that authenticator, or can obtain the credentials needed for the
2430,2431c2473,2477 < Similarly, if a peer is compromised or stolen, an attacker may obtain < credentials required to communicate with one or more authenticators. ---
Similarly, if a peer is compromised or stolen, an attacker can obtain
credentials needed to communicate with one or more authenticators. As noted in [I-D.housley-aaa-key-mgmt] Section 3:
.in +0.3i
2434,2435c2480 < this security claim. However, EAP methods may not enable the negotiation ---
this security claim. However, EAP methods MAY NOT enable the negotiation
2529,2530c2586,2590 < When a Secure Association Protocol is used to establish session ---
When a secure association protocol is used to establish session
2538c2599,2610 < transport may occur from EAP server to peer, or may be bi-directional. ---
transport can occur from EAP server to peer, or can be bi-directional.
2713c2787 < and compound authentication mechanisms may be subject to ---
and compound authentication mechanisms can be subject to
2723,2725c2797,2799 < exchange. Since the compound key must not be known to an attacker < posing as an authenticator, and yet must be derived from quantities < that are exported by EAP methods, it may be desirable to derive the ---
exchange. Since the compound key MUST NOT be known to an attacker posing as an authenticator, and yet MUST be derived from quantities that are exported by EAP methods, it MAY be desirable to derive the
2727c2801 < key hygiene, it is recommended that the compound key used for ---
key hygiene, it is RECOMMENDED that the compound key used for
2735c2809 < communicate directly and credible keywrap is used (see Section 3.8), ---
communicate directly and credible key wrap is used (see Section 3.8),2746c2820
< transported keying material may be recovered by an attacker in control of the
---
transported keying material can be recovered by an attacker in control of the2782c2856,2874
< The maximum lifetime of the transported keying material may be provided, as discussed
---
The maximum lifetime of the transported keying material can be provided, as discussed
2815c2902 < Key usage restrictions may also be included as described in ---
Key usage restrictions can also be included as described in
2824c2911,2914 < peer authorization may be difficult to demonstrate to the authenticator ---
peer authorization can be difficult to demonstrate to the authenticator
2883,2884c2992,2996 < or IPsec is used, the recipient may not ---
or IPsec is used, it is possible that the recipient will not
2919,2920d3031 < within the RADIUS attribute space, it may ---
within the RADIUS attribute space, it can
3074c3223 < Key caching may result in vulnerability to ---
Key caching can result in vulnerability to
3077c3226 < state may be vulnerable to denial of service ---
state can be vulnerable to denial of service
3081,3082c3230,3231 < may wish to limit the persistent state created by an EAP peer. < For example, for each peer an EAP server may choose to limit persistent ---
can limit the persistent state created by an EAP peer. For example, for each peer an EAP server can choose to limit persistent
3087c3236 < Similarly, to conserve resources an authenticator may choose to ---
Similarly, to conserve resources an authenticator can choose to
3093,3095c3242,3244 < Depending on the media, creation of new TSKs < may or may not imply deletion of previously derived TSKs. < Where there is no implied deletion, the authenticator may ---
Whether creation of new TSKs implies deletion of previously derived TSKs depends on the EAP lower layer. Where there is no implied deletion, the authenticator can
3117c3266 < empty string). ---
null string).
3426c3574 < The Peer-Id and Server-Id are the empty string (zero length). ---
The Peer-Id and Server-Id are the null string (zero length).
3435c3583 < are the empty string (zero length). ---
are the null string (zero length).
3444c3592 < The Peer-Id and Server-Id are the empty string (zero length). ---
The Peer-Id and Server-Id are the null string (zero length).
3453c3601 < The Peer-Id and Server-Id are the empty string (zero length). ---
The Peer-Id and Server-Id are the null string (zero length).
3462c3610 < The Peer-Id and Server-Id are the empty string (zero length). ---
The Peer-Id and Server-Id are the null string (zero length).
3480c3628 < is the empty string (zero length). ---
is the null string (zero length).
3498c3646 < is the empty string (zero length). ---
is the null string (zero length).
3524c3672
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.