Thanks for your review. Comments below.
==================
From: "David Harrington" <ietfdbh comcast.net
To: <secdirmit.edu, "'Sam Hartman'"
<hartmans-ietfmit.edu,
<housleyvigilsec.com
CC: pasi.eronennokia.com, dansimonmicrosoft.com, bernardamicrosoft.com,
"'Henrik Levkowetz'" <henriklevkowetz.com
Subject: [secdir] SecDir review, part 1:
draft-ietf-eap-keying-18.txt
Date: Fri, 23 Feb 2007 19:35:55 -0500
I 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
dharringtonhuawei.com
dbharringtoncomcast.net
ietfdbhcomcast.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 methods
>themselves and part of this material can be exported.
In addition to
>export of keying material, EAP methods can also export
associated
143c143
< 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
which
348,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 support
465,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
>.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.
508,510c506,509
< 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 textual
641c649
< 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 layer
862a875
>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 TSKs
877a890,891
>Ciphersuite independence enables EAP methods to be used
with
>new ciphersuites without requiring the methods to be
updated.
886a901,902
>Ciphersuite independence enables EAP methods to avoid
having to
>include ciphersuite-specific code.
890a907,909
>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 if
1347c1378
< 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 Master
1351,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 the
1366c1399
< 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
>a
1370c1403
< 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 Binding
1380c1413
< 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 the
1393c1426
< (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
destination
1586c1619
< 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 by
1933a1979
>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 to
>connectivity loss or that it can pre-authenticate
multiple times with the
>same authenticator,
2025,2028c2071,2074
< 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
---
>sessions is limited, the backend authentication server
can
>refuse to authorize a valid EAP pre-authentication
attempt or can enable
2054c2100
< 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 determine
2076c2122
< authenticator, then the previous authenticator may
potentially know the
session
---
>authenticator, then the previous authenticator can
potentially know the
>session
2160c2203
< 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 NOT
2239c2282
< 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 indeed
2318c2361
< the backend authentication server may return different
authorizations
depending on the
---
>the backend authentication server can return different
authorizations
>depending on the
2340,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
---
>An attacker can cause an EAP peer, authenticator or
>server to reuse a stale key. Use of stale keys can
also
2395,2396c2438,2439
< 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
>the
2782c2856,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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
