Subject: [eap] Re: Issue 78: More terminology

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 13:30:27 -0800 (PST)

The term "EAP server" was meant to be used to denote *either* the
authenticator (when local authentication is occurring) *or* the
authentication server (when authentication is occurring in pass-through
mode).

The phrase "supports EAP method exchanges" seems like it could apply to
*both* the authenticator and the authentication server. So I'm not sure
that this is really a clarification.

With respect to the definition of Silently Discard, this is the original
text from RFC 2284. The intent here is to define auditable events; it is
common practice in security specifications to make normative statements
about which events are auditable in order to ensure that implementations
keep appropriate logs, in order to be able to analyze attacks after the
fact. Therefore it would seem that making these recommendations
non-normative would decrease security.

-------------------------------------------------------
Issue 78: More Terminology
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: Feburary 3, 2003
Document: RFC2284bis-10
Comment type: Technical
Priority: 1
Section: 1.2
Rationale/Explanation of issue:

Item-a: EAP server description
Rationale:
The wording seems a bit confusing.

Change:

"EAP server
The entity that terminates the EAP authentication with the
peer. In the case where there is no backend authentication
server, this term refers to the authenticator. Where the
authenticator operates in pass-through, it refers to the
backend authentication server."

To:

"EAP server
The entity that supports EAP method exchanges with the
peer. This may be in the same device as the authenticator or
it may be a backend authetication server."

------------------------------
Item-b: Silently discard description
Rationale:
Implementation suggestions should be marked as notes. Probably should not
be protocol SHOULDs

Change:

" Silently Discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the event, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter."

to:

" Silently Discard
This means the implementation discards the packet without
further processing.
[Note: Good practice indicates that implementations should
provide the capability of logging the event, including the
contents of the silently discarded packet, and should record
the event in a statistics counter."

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 13:33:24 -0500

> authentication server (when authentication is occurring in pass-through

I think of EAP server as the equivalent of the AS in 802.1x and not the 
same as the authenticator.  This may be a confusion of models, but I think 
it helpful to keep the distinction.

> that this is really a clarification.
only if authenticator is also an AS, which I think it is not.

> non-normative would decrease security.
If it is required for auditability, then I think some reference to the 
requirement would be helpful.  If it is and implementation suggestion then 
I would think it should be noted as such.  This is not a major problem 
either way for me.

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 09:27:15 -0800 (PST)

> it helpful to keep the distinction.

However, that is not how the term is used in RFC 2869, or in RFC 2284bis.
The reason a new term was needed was to avoid having to constantly say
"the authenticator if not in pass-through mode or the authentication
server if in pass-through mode".

> only if authenticator is also an AS, which I think it is not.

The term as used can apply in either case.

> I would think it should be noted as such.  This is not a major problem

Overall, the spec is not clear what events are auditable or not. We should
probably use the term "auditable event" to refer to those things that we
want to keep records of.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 09:57:30 -0800 (PST)

I would propose to open a new Issue 81: Auditable Events to address your
concern about the lack of clarity in audit requirements. I think this will
require going through the document to understand what events we want to be
auditable and which ones are auditable as the document is written today.