Subject: [abfab] Work Item: Update to the EAP Applicability Statement

From: Stefan Winter <[email-masked]>
Date: Mon, 06 Jun 2011 11:03:12 +0200

Hello,

I foolishly volunteered to draft an update to the EAP applicability
statement. With the help of very knowledgable people, in particular Joe
Salowey and Sam Hartman, I made an initial attempt:

http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-00

This obviously isn't perfect, and I would welcome comments of any sort
(including, but not limited to, offers for text and/or co-authorship :-) ).

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 6 Jun 2011 13:20:34 +0300

Hi Stefan,

Here are few comments:

"2.1. Communication of authorisation information: EAP-MSCHAPv2;"

Do you think this (and similar, if any) example indicates that we shall
extend EAP to also signal authorization results, or should this qualify as
one EAP method going beyond the scope? 

I'm inclined to think latter.

"2.4. EAP over IP: PANA"

It'd be more accurate to call it EAP over UDP, or UDP-based EAP lower-layer.

   "The
   original EAP applicability statement states that EAP is applicable in
   cases where "IP layer connectivity may not be available".  The
   wording in the applicability statement leaves open whether the
   transport of EAP over IP is in scope or not. " 

Complete statement from RFC 3748 reads like this:

   "EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available."

So, this provides historical background and an observation. It shouldn't be
taken as "EAP can/shall/should not be carried above IP".

Btw, you may also want to note IKEv2, which also carries EAP over UDP.

   "This limits the use of EAP
   to transport layers which are on top of IP, and provide their own
   ordering guarantees."

Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". There is
UDP, and a UDP-based header in between which ensures the EAP requirements
are satisfied.

   "In most network
   access use cases all access servers that are served by a particular
   EAP server are providing the same or very similar types of service.
   The peer does not need to differentiate between different access
   network services supported by the same EAP server.

Same EAP server can be serving multiple different types of access technology
for the same terminal (e.g., WiFi, WiMAX, 3G). So, the aforementioned
assumption may not be true.

   "A device can be created that impersonates a Network
   Access Service to peers, but actually proxies the authentication to
   the service that newly accepts EAP auths may decrease the security of
   this service even for users who previously used non-EAP means of
   authentication to the service."

Isn't this supposed to be handled by the crypto-secured AAA signaling
between the NAS and the AAA proxy/server? AAA infra would not let anyone
drop some arbitrary AAA node in and get it on the AAA path.

" Pending issuance of
   a Channel Binding RFC, it is thus due to extend the EAP applicability
   statement to include non-network access contexts if - and only if -
   this context mandates channel bindings."

I couldn't parse this well. To me, EAP applicability statement revision is
needed for ABFAB work (even though the ordering of these developments taking
place is not natural :-). And plus you are saying channel binding work is
needed for ABFAB work too.

"  The use of EAP over IP is recommended if - and only if - it is
   transported over a transport layer on top of IP which provides
   ordering guarantees."

I think this goes w/o saying. Whatever requirements exist for EAP
lower-layer applies to any lower layer. Besides, like I  don't think this is
part of "extending" the applicability because it was already allowed.
Nevertheless, an explicit recognition of that possibility can be useful too.

Thanks.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Winter
> Sent: Monday, June 06, 2011 12:03 PM
> To: [email-masked]
> Subject: [abfab] Work Item: Update to the EAP Applicability Statement
> 
> Hello,
> 
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
>

---

From: Stefan Winter <[email-masked]>
Date: Mon, 06 Jun 2011 14:28:02 +0200

Hi,

thanks for these quick comments! Much appreciated!

> I'm inclined to think latter.

I try not to judge this. The point I'm trying to make is: it has been
done, and it seems to work well. Whether or not it is something that
should be expressly endorsed or better not - that is something that
should be discussed. Same goes for the "change password" stuff in
EAP-MSCHAPv2. There, I'm even less sure that it is something that should
be endorsed. But it exists, and works - for some at least.

I think it would be good to have more examples of both aspects:
authorisation information and account management. After a few off-line
discussions, it seems that transport of authorisation information is
something that happens on a broader scale than just EAP-MSCHAPv2; I've
heard that at least 3GPP does the same thing with something called
AT_TRUST_IND within EAP-AKA. But, knowing nothing about 3GPP, I didn't
dare use this as an example.

The "change password" things though - I don't have any other example for
that on the top of my head right now. If this feature is a singleton in
EAP-MSCHAPv2, maybe it's not a good indicator of what should be done
within EAP.

> It'd be more accurate to call it EAP over UDP, or UDP-based EAP lower-layer.

I was trying *not* to mention UDP specifically. SCTP might make a
just-as-good lower-layer for EAP, and runs on IP. PANA should only serve
as an example for the section "EAP over IP"; I guess that wasn't very clear.

> Btw, you may also want to note IKEv2, which also carries EAP over UDP.

Point taken, I'll enlarge the quote and add IKEv2.

> UDP, and a UDP-based header in between which ensures the EAP requirements

Well, the applicability statement should also provide limits on what NOT
to do. So, it's good that PANA and IKEv2 use UDP. But some ill-advised
person might envisage "EAP over ICMP", which is on top of IP, but does
not provide ordering guarantees. I think it would be good to tell such a
person that they should... do something else.

> assumption may not be true.

That's a good point; it depends largely on how one defines "very
similar". I was just about to write back "but these are all just IP
network access technologies" - but they aren't. IIRC, EAP-AKA in the
3GPP world isn't only used for IP network data access, it's also for
good old voice telephony (is that right? I think I mentioned before that
the 3GPP world is a mystery to me ... ).

Still, even with data being "different" - it is still a network.
Circuit-switched as opposed to packet-switched alright, but for some, it
might still qualify as being "very similar".

IOW, the text still has a bit of leeway for interpretation here. I'm
happy to get text suggestions.

> drop some arbitrary AAA node in and get it on the AAA path.

That's not where I understood the impersonation threat to come from.
Isn't it more like:

Consider user A who uses a NAS B to get network access, where B
authenticates the user credentials to EAP server C.
A also reads his email via IMAP, but the IMAP server will do plain old
PAP, against server C (not speaking EAP though).

B can't read the user's email because it doesn't know A's credentials at
C; it's just a pass-through.

Now, the IMAP administrative personnel enables IMAP server access with
abfab technology, i.e. GSSAPI and EAP, authenticating against the same
server C (now speaking EAP).

B's operator would now love to read the user's email, and waits for the
user to login via B (network access!) next time. He then triggers a
GSSAPI-based EAP authentication at the IMAP server, and relays the EAP
conversation from A to the IMAP server, which uses it to authenticate
"A" at C. B (or, the sinister administrator of B) now has access to A's
mails without actually being A - a successful impersonation.

B will never learn the actual credential of A; that is hopefully
cryptographically secured inside the EAP mechanism, but it may get
access to another service in the name of the user.

So, while B and IMAP are both part of the same AAA infrastructure, they
only have a per-service trust towards the EAP server; the AAA
infrastructure doesn't preclude the two from cheating over each other.

> needed for ABFAB work too.

This is not necessarily about ABFAB in a narrow sense. It's more like:
"using EAP for access to multiple services requires channel bindings".
Since one usage of EAP is for the service "network access" ever since,
adding any other second use triggers the need to add channel bindings.
But yes, ABFAB is such a "second use".

> Nevertheless, an explicit recognition of that possibility can be useful too.

Well, yes, it doesn't hurt to be explicit.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 7 Jun 2011 16:04:00 +0300

> > Sure thing. But neither IKEv2 nor PANA are "EAP naked over IP". There
> > is UDP, and a UDP-based header in between which ensures the EAP
> > requirements are satisfied.
> 
> Well, the applicability statement should also provide limits on what
> NOT to do. 

Here your I-D is sliding into talking about "EAP lower-layer requirements"
which is a different thing than "EAP applicability statement".

> So, it's good that PANA and IKEv2 use UDP. But some ill-
> advised person might envisage "EAP over ICMP", which is on top of IP,
> but does not provide ordering guarantees. I think it would be good to
> tell such a person that they should... do something else.

I don't think there is anything to prevent an ICMP-based EAP lower-layer
being designed.

> > Same EAP server can be serving multiple different types of access
> > technology for the same terminal (e.g., WiFi, WiMAX, 3G). So, the
> > aforementioned assumption may not be true.
> 
> good old voice telephony (is that right? I think I mentioned before
> that the 3GPP world is a mystery to me ... ).
> 
> Circuit-switched as opposed to packet-switched alright, but for some,
> it might still qualify as being "very similar".
> 
> > between the NAS and the AAA proxy/server? AAA infra would not let
> > anyone drop some arbitrary AAA node in and get it on the AAA path.
> 
> B can't read the user's email because it doesn't know A's credentials
> at C; it's just a pass-through.
> 

B is a NAS. It's not allowed to source AAA messages for non-NAS related
procedures (e.g., IMAP). Wouldn't this simply solution handle the issue?

> > I couldn't parse this well. To me, EAP applicability statement
> > revision is needed for ABFAB work (even though the ordering of these
> > developments taking place is not natural :-). And plus you are saying
> > channel binding work is needed for ABFAB work too.
> 
> > lower-layer applies to any lower layer. Besides, like I  don't think
> > this is part of "extending" the applicability because it was already
> allowed.

I'm afraid this is mixing up requirements and applicability discussions.
Probably any transport protocol (including pigeons) is fine as an EAP
lower-layer as long as it satisfies the EAP lower-layer requirements. 
But carrying anything or doing anything with EAP is not fine, and that's
where the applicability statement comes into the picture.

On a more radical note, why EAP has applicability statement, but no(?) other
IETF protocol has one? What happens if we get rid of the applicability
statement completely?

Cheers,

Alper

> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Stefan Winter
> >> statement. With the help of very knowledgable people, in particular
> >> Joe Salowey and Sam Hartman, I made an initial attempt:
> >>
> >> This obviously isn't perfect, and I would welcome comments of any
> >> sort (including, but not limited to, offers for text and/or
> >> co-authorship :-
> >> ) ).
> >>
> >> Greetings,
> >>
> >> Stefan Winter
> >>
> >> --
> >> Stefan WINTER
> >> Ingenieur de Recherche
> >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale
> >> et de la Recherche 6, rue Richard Coudenhove-Kalergi
> >> L-1359 Luxembourg
> >>
> >> Tel: +352 424409 1
> >> Fax: +352 422473
> >>
> >
> 
> 
> --
> Stefan WINTER
> Ingenieur de Recherche

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Jun 2011 09:31:25 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    >> > "This limits the use of EAP > to transport layers which are on
    >> top of IP, and provide their own > ordering guarantees."
    >> >
    >> > Sure thing. But neither IKEv2 nor PANA are "EAP naked over
    >> IP". There > is UDP, and a UDP-based header in between which
    >> ensures the EAP > requirements are satisfied.
    >> 
    >> Well, the applicability statement should also provide limits on
    >> what NOT to do.

    Alper> Here your I-D is sliding into talking about "EAP lower-layer
    Alper> requirements" which is a different thing than "EAP
    Alper> applicability statement".

I believe that requirements of the domain of applicability--in this case
lower layer requirements--are in scope for this draft.
My current position is that I support this discussion.

    >> authenticates the user credentials to EAP server C.  A also reads
    >> his email via IMAP, but the IMAP server will do plain old PAP,
    >> against server C (not speaking EAP though).
    >> 
    >> B can't read the user's email because it doesn't know A's
    >> credentials at C; it's just a pass-through.
    >> 
    >> Now, the IMAP administrative personnel enables IMAP server access
    >> with abfab technology, i.e. GSSAPI and EAP, authenticating
    >> against the same server C (now speaking EAP).
    >> 
    >> B's operator would now love to read the user's email, and waits
    >> for the user to login via B (network access!) next time. He then
    >> triggers a GSSAPI-based EAP authentication at the IMAP server,
    >> and relays the EAP conversation from A to the IMAP server, which
    >> uses it to authenticate "A" at C. B (or, the sinister
    >> administrator of B) now has access to A's mails without actually
    >> being A - a successful impersonation.
    >> 
    >> cryptographically secured inside the EAP mechanism, but it may
    >> get access to another service in the name of the user.
    >> 
    >> So, while B and IMAP are both part of the same AAA
    >> infrastructure, they only have a per-service trust towards the
    >> EAP server; the AAA infrastructure doesn't preclude the two from
    >> cheating over each other.

    Alper> B is a NAS. It's not allowed to source AAA messages for
    Alper> non-NAS related procedures (e.g., IMAP). Wouldn't this simply
    Alper> solution handle the issue?

B is malicious. It doesn't care what you think it is allowed to do.
Something in the system needs to prevent B from acting improperly.
The logical place to enfore that is at the EAP server.
To do that, the EAP server needs to know what the user thought they were
trying to do--it needs channel binding.

    Alper> I'm afraid this is mixing up requirements and applicability
    Alper> discussions.  Probably any transport protocol (including
    Alper> pigeons) is fine as an EAP lower-layer as long as it
    Alper> satisfies the EAP lower-layer requirements.  But carrying
    Alper> anything or doing anything with EAP is not fine, and that's
    Alper> where the applicability statement comes into the picture.

    Alper> On a more radical note, why EAP has applicability statement,
    Alper> but no(?) other IETF protocol has one? What happens if we get
    Alper> rid of the applicability statement completely?

    Alper> Cheers,

I would be strongly against removing the applicability statement
entirely. One of the main reasons for this is exactly because we have
found requirements such as channel binding that we need to place on
other uses of EAP.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 8 Jun 2011 16:09:31 +0300

> My current position is that I support this discussion.

I find this very confusing. As you might know, RFC 3748 already has a
dedicated section "3.1 Lower Layer Requirements". Are you intending to add
to that, or modify that too in this "applicability statement" I-D? 

> trying to do--it needs channel binding.

C knows B is a "NAS", not an "IMAP server". 
Therefore C would not let an IMAP session be AAAed on the B.

Equivalent of that is what is relied upon in order to prevent a WiFi NAS to
pretend like a WiMAX NAS. 

I'm not saying channel binding is unnecessary. I'm saying the scenario you
are providing does not require channel binding.

> found requirements such as channel binding that we need to place on

My concern with the applicability statement is that, it can be misused
unless it is perfectly defined, which is not possible by definition. This is
very tricky. Do we have good experience and examples with defining
applicability statements in IETF? (The ones that I have seen so far have
been bad experiences :-)

Btw, can't we say the same thing for any authentication
method/mechanism/protocol (not just EAP)? If I'm getting
authenticated/authorized for Service X using method Y, there needs to be
some way of ensuring that the other end-point of authentication also thinks
I'm up for Service X. Does TLS, HTTP-digest, IKE, etc. all take care of
that? I think not. So, we should think if they also need channel-binding, or
if they have some substitute solutions. Any thoughts on that?

Alper

Alper

---

From: Stefan Winter <[email-masked]>
Date: Thu, 09 Jun 2011 11:25:46 +0200

Hi,

(only replying to the impersonation part)

> are providing does not require channel binding.

C knows that B is a NAS. C knows that IMAP is a NAS. What C doesn't know
is that B initiated a TCP connection on the IMAP4 port, started an IMAP
conversation, and, when asked to authenticate via GSSAPI/EAP uses a
carbon copy of the EAP authentication currently going on with A for
network access.

I hope that makes the attack scenario clearer...

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jun 2011 11:05:27 -0500

> I hope that makes the attack scenario clearer...

Right, this is just a sort of MITM cut-n-paste attack.  It's made
feasible only by the addition of a new context from which
authentication messages may be taken and played elsewhere.  Another
factor that makes this feasible is that in the original context
there's either no additional confirmation of context establishment
than that provided by the authentication message exchange, OR failure
of that is often silently ignored.

This is an example of a good reason for an applicability statement.
Simply adding more contexts in which a technology might be used can
render insecure.  This is also a good reason to not design mechanisms
with this sort of weakness built-in...

We've faced similar problems in the GSS and Kerberos worlds before.
The best example is SSHv2, where we used the same service name
('host') as in other kerberized and GSSified protocols (rsh, telnet,
FTP), where some of those other protocols had options to not perform
any confidentiality nor integrity protection after authentication.
This EAP issue is the same sort of problem that we faced when adding
GSS support to SSHv2.

Nico
--

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:07:24 -0700

Hi Stefan,

Thanks for putting this together.  I have some detailed comments on the subsections in section 2 which I will provide under separate subjects.    In general I would like the draft to be more explanatory about when it is a good idea to move beyond the applicability statement.  I'll include some of this in my comments on section 2, some of which may also be incorporated into section 4.   I do not think we should rename the protocol as suggested in section 3.    

Cheers,

Joe

On Jun 6, 2011, at 2:03 AM, Stefan Winter wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:07:32 -0700

There are several cases where authorization data is carried in EAP.  In the case you site there is information about an authorization result that is carried within EAP.   There are also cases where more detailed information is delivered to the peer.  One example is the AT_TRUST_IND attribute that has been defined by 3GPP within EAP-AKA/SIM.  This attribute allows the authentication server to signal to the peer whether the access network is trusted.    Unfortunately, EAP methods do not have a generic way of carrying authorization information.  Some methods will not have the capability to carry specific attributes this so it will not be possible to move to a different EAP type to support  different credentials in these deployments.  This breaks the plug-ability of EAP methods.   Another potential issue here is that authorization information is often deployment or technology specific, which breaks the media independent properties of EAP.    I would not recommend the general addition of authorization information to EAP unless a generic mechanism for communicating authorization information within EAP methods is developed.  

Here is a suggested revision for this section:

"2.1.  Communication of authorisation information

In some cases EAP methods carry authorization information.  An EAP-AKA attribute,  AT_TRUST_IND [3GPP TS 24.302], has been defined in 3GPP to allow the authentication server to signal to the EAP peer if it is attached to a trusted network.   If the attribute indicates the network is not trusted then the EAP peer would establish an IPSEC tunnel to its home network to protect its communications.   If the attribute indicates  a trusted network then the EAP Peer may send its traffic without establishing an IPSEC tunnel since the network is authorized to handle it.  

It is also common for EAP methods to communicate information about access control decisions beyond just success and failure.  For example, MSCHAPv2 signals (lack of) authorisation of an authenticated user to use a service.  An MSCHAPv2 failure packet as defined in section 6 of [RFC2759] can indicate condition 646 "Restricted Logon hours".  This determination is an authorisation check which happens subsequent to the authentication step (a user needs to be positively identified to correlate his identity to a list of permitted logon hours).

This use of EAP is not covered by the EAP applicability statement since it goes beyond authentication.    There are some potential issues that can arise from carrying authorization data in EAP.  First,  there is no generic mechanism for EAP methods to carry authorization data.    In order to make use of and communicate the authorization data the EAP method will have to provide custom interfaces and capabilities.  This will inhibit the ability for different EAP methods to be used in a pluggable fashion within deployments.  It addition, if the authorization information is specific to a particular media, then it will break the media independent property of EAP.  

Extending individual EAP methods to carry authorization data for a specific deployment, technology, or media type is NOT RECOMMENDED.    If the authorization data is informative such that the system operation is not significantly change if it is missing and if it is of a general nature then authorization data MAY be carried.   If there is significant need for deployment specific, technology specific or media specific authorization information to be carried within EAP methods then a well defined mechanism and framework must be defined so the type of authorization data can be independent of the EAP method.  This would allow the deployment of different EAP methods to support peers and servers with different credential types. "

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:07:57 -0700

I think any EAP lower layer should be required to implement validation of the MSK between the EAP peer and EAP authenticator.    If you are going to mention re-ordering you might also mention fragmentation.  Here is some suggested text, but I don't think I captured all the information from the thread on this topic. 

"2.4.  EAP over IP

The original EAP applicability statement states that EAP is applicable in cases where "IP layer connectivity may not be available".  The wording in the applicability statement leaves open whether the transport of EAP over IP is in scope or not.  Since protocols which carry EAP over IP already exist and have been deployed, it is due to make this use case explicit and reflect it in the revised applicability statement.  Examples of EAP over IP protocols include PANA protocol [RFC5191] and IKEv2.  Since protocols which carry EAP over IP already exist and have been deployed, it is due to make this use case explicit and reflect it in the revised applicability statement.  

There are some considerations to consider when EAP is used over other transports. The statement needs to take into account though that EAP requires ordering guarantees from its lower layers, which are not delivered by IP in itself.  This limits the use of EAP to transport layers which are on top of IP, and provide their own ordering guarantees.  In addition, many EAP methods do not provide fragmentation so lower layers that limit the payload size may artificially constrain the use of some EAP methods.  Since it is common for the authentication server to be separated by from the authenticator lower layer protocols MUST provide a mechanism for the EAP  Peer and EAP authenticator to prove possession of the EAP MSK to ensure the EAP Peer and EAP authenticator are authenticated to one another. "

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:08:38 -0700

> to that, or modify that too in this "applicability statement" I-D? 

[Joe]  Perhaps.  The applicability statement was not created without reason.  There are many cases where the environment where EAP is used, including the lower layer, is an important consideration.   In expanding the applicability statement there may be additional requirements on the environment for EAP to be used successfully for a particular application. 

> applicability statements in IETF? (The ones that I have seen so far have

[Joe]  Perhaps, but we already have one.  I think it would be good to provide more explanation around why such statements are made.

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:07:46 -0700

Some aspects of account management, such as those associated with the authentication credential seem like they may be a good fit.  Others, such as paying bills and adding services probably are not as these sorts of tasks tend to be deployment specific.  

Suggested text:

"2.3.  Credential Management

Another enhancement to EAP is in the area of credential management.  For example,  EAP-MSCHAPv2  includes limited support for user account management, namely the possibility for a user to change his password, should it have expired.  This is defined in section 7 of [RFC2759].

This use of EAP is not covered by the EAP applicability statement since it goes beyond authentication.  In general, account management tasks within EAP SHOULD be limited to tasks directly associated with the credentials used for authentication.  The renewal of a password or the maintenance of a PIN code are examples of this type of task.  Tasks that are of a more general nature such as payment or service maintenance are NOT RECOMMENDED since they are likely to be very deployment specific leading to EAP methods that are not reusable in other environments.  In addition these more general tasks often involve extensive user interaction and the exchange of additional data which can be dangerously close to "bulk data transport". "

---

From: Joe Salowey <[email-masked]>
Date: Thu, 9 Jun 2011 18:07:39 -0700

There are definite advantages to doing endpoint assessment checks at the time of network access, however this use of EAP is not covered by the EAP applicability statement since it is not authentication.   EAP has was designed for user authentication.  Many deployments rely upon the EAP method to authenticate the EAP Peer and EAP Server and generate a Peer Name and Server Name for authorization and accounting purposes.   Endpoint assessment techniques do not always provide this type of authentication and naming.  In addition, if the assessment data is tightly coupled with a specific EAP authentication method it will restrict the plug-ability of EAP methods in different deployments.   The draft should RECOMMEND that endpoint assessment data  be incorporated into an EAP exchange along with existing peer and sever authentication as an enhancement to the authorization process.  One mechanism to achieve this is to exchange the NEA data within an EAP tunnel method that can also provide the peer and server authentication. 

Here is some suggested text for section 2.2

"2.2.  Endpoint Assessment

Recently, EAP methods have been used to carry endpoint posture information to assess the health of an endpoint.  This is the topic of the the IETF "Network Endpoint Assessment" NEA working group.  This working group is developing mechanisms for carrying posture data over EAP.  
The information exchanged is unrelated to user authentication - the information covers the state of the computing device only, independently of the user who is using it.  Implementations of this technology have been developed that embed the posture data within another EAP method or within a stand alone method.  

This use of EAP is not covered by the EAP applicability statement since it is not authentication, which is what EAP was designed to do.  Many deployments rely upon the EAP method to authenticate and generate an EAP Peer Name and EAP Server Name which are then used for authorization and accounting purposes.   Endpoint assessment techniques do not always provide the type of authenticated name used for authorization and accounting.   It is RECOMMENDED that endpoint assessment data be incorporated into an EAP exchange along with existing peer and sever authentication as an enhancement to the authorization process.  One mechanism to achieve this is to exchange the NEA data within an EAP tunnel method that can also provide the peer and server authentication. 

The size of the posture data may also be a concern when performing endpoint assessment.  Care should be taken to limit the amount and type of data communicated in the assessment process.  For example, it is inappropriate to transfer software patches to be applied on the endpoint over the EAP channel since this would fall into the category of "bulk data transport".  "

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Jun 2011 12:48:29 +0900

I agree with Joe that we don't need to rename the protocol name.
Extensible Authentication Protocol is good enough.

Yoshihiro Ohba

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jun 2011 10:24:50 -0400

I support Joe's proposed revision to authorization data.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jun 2011 10:42:40 -0400

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

    Joe> I think any EAP lower layer should be required to implement
    Joe> validation of the MSK between the EAP peer and EAP
    Joe> authenticator.  If you are going to mention re-ordering you
    Joe> might also mention fragmentation.  Here is some suggested text,
    Joe> but I don't think I captured all the information from the
    Joe> thread on this topic.  "2.4.  EAP over IP

I agree with this.  I'm actually kind of uncomfortable though casting
this all in terms of EAP over IP. I think that's the wrong focus for the
discussion.  I'm not objecting to your text--it improves the document--I
just wonder whether we could take another pass and de-emphasize the over
IP issue.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Jun 2011 10:43:54 -0400

Do we want to discuss NEA at all in this document?  I kind of thought we
were tasked with expanding the EAP applicability statement to cover
application authentication, not to having open season on revising core
EAP applicability.

--Sam

---

From: Stefan Winter <[email-masked]>
Date: Fri, 17 Jun 2011 15:51:55 +0200

Hi,

> application authentication, not to having open season on revising core

Well, the chance to update the EAP applicability statement doesn't come
along every day. I think that while we're at it, we should work to cover
all ground that is currently going on in the IETF. NEA is doing new
chartered work that goes beyond the EAP applicability statement - and we
are changing that same statement simultaneously. IMHO, it would be a
shame not to incorporate that work into the applicability considerations.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Steve Hanna <[email-masked]>
Date: Fri, 17 Jun 2011 17:52:07 -0400

I agree. No point in revising the EAP applicability statement twice! If 
you want a NEA expert to help on the project, count me in.

Thanks,

Steve Hanna
NEA WG co-chair