Subject: [abfab] Summary of proposed changes to eat applicability document

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 22 Feb 2013 23:37:27 +0000

After going through the comments on the list here is where I think we are with changes to the document:

1) Section 3 

OLD
   It is important
   for the protocol carrying EAP to prove possession of the EAP MSK
   between the EAP Peer and EAP Authenticator.

NEW
The protocol carrying EAP MUST prove possession of the EAP MSK
   between the EAP Peer and EAP Authenticator.

ADD

In the context of EAP for Application-Layer Access the application is providing the EAP Lower Layer.   Applications protocols vary so their specific behavior and transport characteristics needs to be considered when determining their retransmission and re-authentication behavior as discussed in section 3.  

3)  Retransmissions

ADD 

2.1 Retransmission

In EAP, the authenticator is responsible for retransmission. By default
EAP assumes that the lower layer (the application in this context) is
unreliable. The authenticator can send a packet whenever its
retransmission timer triggers. In this mode, applications need to be able to receive and process 
EAP messages at any time during the authentication conversation.

Alternatively, EAP permits a lower layer to set the retransmission timer
to infinite. When this happens, the lower layer becomes responsible for
reliable delivery of EAP messages. Applications that use a lock-step or
client-driven authentication protocol might benefit from this approach.

In addition to retransmission behavior applications need to deal with
discarded EAP messages. For example, whenever some EAP methods receive  erroneous
input, these methods discard the input rather than generating an error
response. If the erroneous input was generated by an attacker,
legitimate input can sometimes be received after the erroneous
input. Applications MUST handle discarded EAP messages,
although the specific way in which discarded messages will be handled
depend on the characteristics of the application. Options include
failing the authentication at the application level, requesting an EAP 
retransmit and waiting for additional EAP input.   

Specifications of how EAP is used for application authentication SHOULD
document how retransmission and message discards are handled.

4) Re-Authentication

ADD

2.2 Re-Authentication

EAP lower layers MAY provide a mechanism for re-authentication to happen
within an existing session [RFC 3748]. Diameter standardizes a mechanism
for a AAA server to request re-authentication [RFC
4005]. Re-authentication permits security associations to be updated
without establishing a new session. For network access, this can be
important because interrupting network access can disrupt connections
and media.

Some applications might not need re-authentication support. For example
if sessions are relatively short-lived or if sessions can be replaced
without significant disruption, re-authentication might not provide
value. Protocols like HypertextTransport Protocol (HTTP) and Simple
Mail Transport Protocol (SMTP) are examples of protocols where
establishing a new connection to update security associations is likely
to be sufficient.

Re-authentication is likely to be valuable if sessions or connections
are long-lived or if there is a significant cost to disrupting them.

Another factor may make re-authentication important. Some protocols only
permit one part in a protocol (for example the client) to establish a
new connection. If another party in the protocol needs the security
association refreshed then re-authentication can provide a mechanism to
do so.

Lower layers SHOULD describe whether re-authentication is provided and
which parties can initiate it.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Feb 2013 18:53:44 -0500

Looks good to me.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 22 Feb 2013 17:46:44 -0800

I have no immediate qualms about this text.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Joseph Salowey (jsalowey)
> Sent: Friday, February 22, 2013 3:37 PM
> To: [email-masked]
> Subject: [abfab] Summary of proposed changes to eat applicability document
> 
> In the context of EAP for Application-Layer Access the application is
providing
> the EAP Lower Layer.   Applications protocols vary so their specific
behavior
> and transport characteristics needs to be considered when determining
their
> retransmission and re-authentication behavior as discussed in section 3.
> 
> 
> 3)  Retransmissions
> 
> ADD
> 
> 2.1 Retransmission
> 
EAP
> assumes that the lower layer (the application in this context) is
unreliable.
> The authenticator can send a packet whenever its retransmission timer
> triggers. In this mode, applications need to be able to receive and
process
> Alternatively, EAP permits a lower layer to set the retransmission timer
to
> infinite. When this happens, the lower layer becomes responsible for
reliable
> delivery of EAP messages. Applications that use a lock-step or
client-driven
> authentication protocol might benefit from this approach.
> 
> discarded EAP messages. For example, whenever some EAP methods
> receive  erroneous input, these methods discard the input rather than
> generating an error response. If the erroneous input was generated by an
> attacker, legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages, although the
> specific way in which discarded messages will be handled depend on the
> characteristics of the application. Options include failing the
authentication at
> the application level, requesting an EAP
for
> a AAA server to request re-authentication [RFC 4005]. Re-authentication
> permits security associations to be updated without establishing a new
> session. For network access, this can be important because interrupting
> network access can disrupt connections and media.
> 
> Some applications might not need re-authentication support. For example if
> sessions are relatively short-lived or if sessions can be replaced without
> significant disruption, re-authentication might not provide value.
Protocols
> like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol
> (SMTP) are examples of protocols where establishing a new connection to
> update security associations is likely to be sufficient.
> 
> Re-authentication is likely to be valuable if sessions or connections are
long-
> lived or if there is a significant cost to disrupting them.
> 
> permit one part in a protocol (for example the client) to establish a new
> connection. If another party in the protocol needs the security
association
> refreshed then re-authentication can provide a mechanism to do so.
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Leif Johansson <[email-masked]>
Date: Sat, 23 Feb 2013 10:34:52 +0100

> After going through the comments on the list here is where I think we are with changes to the document:
Just to be clear - the chairs consider this a consensus call for
(hopefully final)
changes to the eap applicability statement.

We hope and expect to be able to WGLC the resulting version of the document.

        Cheers Leif

---

From: <[email-masked]>
Date: Sat, 23 Feb 2013 16:01:27 +0000

Hi Joe,

The proposed new Sections "2.1 Retransmission" and "2.2 Re-Authentication" are intended to be added to draft-ietf-abfab-eapapplicability (and not intended be added to RFC 3748), right?

If so, then the following sentence in Section 2.2 should be written from application perspective in the same way as Section 2.1 for consistency:

"Lower layers SHOULD describe whether re-authentication is provided and which parties can initiate it."

Applications SHOULD describe whether re-authentication is provided and which parties can initiate it.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Salowey (jsalowey)
Sent: Saturday, February 23, 2013 8:37 AM
To: [email-masked]
Subject: [abfab] Summary of proposed changes to eat applicability document

1) Section 3 

OLD
   It is important

NEW

ADD

3)  Retransmissions

ADD 

2.1 Retransmission

In EAP, the authenticator is responsible for retransmission. By default EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be able to receive and process EAP messages at any time during the authentication conversation.

Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach.

In addition to retransmission behavior applications need to deal with discarded EAP messages. For example, whenever some EAP methods receive  erroneous input, these methods discard the input rather than generating an error response. If the erroneous input was generated by an attacker, legitimate input can sometimes be received after the erroneous input. Applications MUST handle discarded EAP messages, although the specific way in which discarded messages will be handled depend on the characteristics of the application. Options include failing the authentication at the application level, requesting an EAP retransmit and waiting for additional EAP input.   

Specifications of how EAP is used for application authentication SHOULD document how retransmission and message discards are handled.

4) Re-Authentication

ADD

2.2 Re-Authentication

EAP lower layers MAY provide a mechanism for re-authentication to happen within an existing session [RFC 3748]. Diameter standardizes a mechanism for a AAA server to request re-authentication [RFC 4005]. Re-authentication permits security associations to be updated without establishing a new session. For network access, this can be important because interrupting network access can disrupt connections and media.

Some applications might not need re-authentication support. For example if sessions are relatively short-lived or if sessions can be replaced without significant disruption, re-authentication might not provide value. Protocols like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol (SMTP) are examples of protocols where establishing a new connection to update security associations is likely to be sufficient.

Re-authentication is likely to be valuable if sessions or connections are long-lived or if there is a significant cost to disrupting them.

Another factor may make re-authentication important. Some protocols only permit one part in a protocol (for example the client) to establish a new connection. If another party in the protocol needs the security association refreshed then re-authentication can provide a mechanism to do so.

Lower layers SHOULD describe whether re-authentication is provided and which parties can initiate it.
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Sat, 23 Feb 2013 11:16:44 -0500

>>>>>   <[email-masked]> writes:

I'm fine with this change.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 24 Feb 2013 13:46:55 +0100

> I'm fine with this change.

I *strongly* urge others on the list to chime in with their +1 or
detailed descent at this point.

        Cheers Leif

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 25 Feb 2013 16:38:10 +0000

Good catch Yoshi,  I will make this change.

Thanks,

Joe
On Feb 23, 2013, at 8:01 AM, <[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Wed, 27 Feb 2013 23:36:20 +0200

> client-driven authentication protocol might benefit from this approach.

It'd be useful to explain why so, even briefly. 

> retransmit and waiting for additional EAP input.   

Are these the only three options for how apps must handle discarded EAP messages? If so, we should state that clearly. If not, then the "MUST handle" statement is not meaningful at all. Unless we state specific way of handling, or provide some general guidelines (e.g., characteristics of handling), "MUST handle" does not mean anything to implementors.

Also, as I had stated earlier, this requirement implies an interface between the EAP method layer and the EAP lower-layer. Such an interface does not exist, there is EAP in between. 
This requirement has additional implications on EAP methods too. Existing EAP methods need to be modified??

> document how retransmission and message discards are handled.

Why not MUST? 

> are long-lived or if there is a significant cost to disrupting them.

There's a bit of a terminology confusion here, I believe.

I think the intention is to state that we don't need to run EAP again and again in order to maintain an always-on security association. It is OK to let EAP sessions expire. We can run EAP again if and when we need a security association again. One could call this "re-authenticaiton".

On the other hand, letting the security association expire and having to run EAP again on-demand can also be called "re-authentication".

> which parties can initiate it.

I'd say "MUST" here too.

Alper

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Feb 2013 17:08:07 -0500

I believe these comments have essentially been made before.  I'm happier
coming to closure on the text we have than spending more time refining
it.
Obviously if people jump in and want to work on these issues, then I'll
end up in the rough.
I just wanted to state an opinion in favor of being done rather than
spending more time.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Wed, 27 Feb 2013 23:52:22 +0100

> detailed descent at this point.
Still waiting for more support or dissent

---

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Feb 2013 09:40:18 +0200

Yes I made the same comment before. 
Back then and now we understand you don't see them as issues. 
We better get confirmation from other folks too before proceeding again.
You disagreeing and everyone else being silent is not really comforting to proceed, IMHO.

Can someone else please take a stab at the points I'm raising and let us know whether they think they are issues or not?

---

From: Josh Howlett <[email-masked]>
Date: Thu, 28 Feb 2013 10:20:27 +0000

I am happy with the proposed text.

I have made some comments to Alper's issues below.

Josh.

>It'd be useful to explain why so, even briefly.

I'm happy with this description. It is somewhat terse, but it meets the
need.

>Are these the only three options for how apps must handle discarded EAP
>messages? If so, we should state that clearly. If not, then the "MUST
>handle" statement is not meaningful at all. Unless we state specific way
>of handling, or provide some general guidelines (e.g., characteristics of
>handling), "MUST handle" does not mean anything to implementors.

The applicability statement is describing a behaviour that needs to be
considered by applications if they want to interoperate. It is reasonable
to leave the question of what it means to successfully interoperate as an
exercise for the application, because that will vary from application to
application.

>Also, as I had stated earlier, this requirement implies an interface
>between the EAP method layer and the EAP lower-layer. Such an interface
>does not exist, there is EAP in between.

I don't follow this logic. While one can argue that such an interface
might be useful, that does not imply that one is necessary. There is
running code to prove it :-)

>> document how retransmission and message discards are handled.

See the first point.

>I think the intention is to state that we don't need to run EAP again and
>again in order to maintain an always-on security association. It is OK to
>let EAP sessions expire. We can run EAP again if and when we need a
>security association again. One could call this "re-authenticaiton".
>
>On the other hand, letting the security association expire and having to
>run EAP again on-demand can also be called "re-authentication".

I regret that I don't understand what point is being made here. The text
seems pretty clear to me.

>> which parties can initiate it.

Ditto the first point.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Alper Yegin <[email-masked]>
Date: Thu, 28 Feb 2013 13:47:27 +0200

> I'm happy with this description. It is somewhat terse, but it meets the

I don't think readers' understanding can make the jump from 1st+2nd sentences to the 3rd sentence without having followed all the discussions on the list.
I'm merely concerned about that. If I'm the only one concerned, then that's fine….

> considered by applications if they want to interoperate.

This "MUST" cannot be implemented. It's not clear what an implementor "must" be doing to comply.
This is merely telling us "there's a problem, you MUST deal with it". 
This reads more like recognition of an issue, rather than a solution.

We should either have a very clear "MUST do this …", or
Define what the problem is, and leave it to the application designers to deal with it in their own terms. (And even in this case not sure if you can use "MUST"… maybe, maybe not.)
We have neither of the above.

> It is reasonable

So, how do you deal with this in your implementation? If the EAP authentication method (e.g., EAP-TLS, EAP-AKA, etc.) discards a message, who takes what action?

>>> document how retransmission and message discards are handled.

I was suggesting using MUST instead of SHOULD. I didn't understand how your first point addresses my comment here.

> seems pretty clear to me.

I'm confused about the terms "re-authenticaiton" and "session". 

To me, both of the following cases qualify as "re-authentication":
- Either the EAP peer or the EAP authenticator initiates new EAP authentication before the current EAP SA expires. One or more EAP authentication sessions live inside the same EAP lower-layer session.
- EAP SA can be left to expire. The EAP lower-layer session may or may not expire in response to the EAP SA expiration. Whoever needs EAP SA is responsible for initiating EAP authentication. For example, when the server has some data to transmit but there is no SA available, then it'd trigger authentication.

Having said both qualifies as "re-auth" in my understanding, I believe the text is referring to the former type. 
Maybe we need some additional terminology to distinguish the two type from each other.

>>> which parties can initiate it.

I was suggesting using MUST instead of SHOULD. I didn't understand how your first point addresses my comment here.

Alper

---

From: "Leif Johansson" <[email-masked]>
Date: Thu, 28 Feb 2013 14:46:33 +0100

> This reads more like recognition of an issue, rather than a solution.

I' going to weigh in (as an individual) on this point. 

There is (imo) nothing inherently problematic about calling out a problem that needs to be addressed in another specification, especially when writing an applicability statement.

      Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Feb 2013 12:20:26 -0500

Josh, Alper, I'd like to come back to one point.

Alper asked why we wanted to have SHOULD describe re-authentication and
retransmission behavior rather than MUST describe that behavior.

When we use the SHOULD 2119 keyword it's because we believe there are
unusual circumstances where violating the SHOULD is the right thing to
do.
SHOULD is a fairly strong requirement, but it does not apply 100% of the
time.

The primary reason I think that should be a SHOULD not a MUST is that I
think documenting the lower layer (which is to say the application) is
only a SHOLUD.
If a company creates a proprietary application, I don't think it's our
business to mandate that they document certain things.

I cannot think of a case where it would be appropriate for a document in
the IETF describing the use of EAP for application authentication should
leave out discussion of retransmission and discard behavior.  (We'll
need to go fix draft-ietf-abfab-gss-eap as it does not discuss discard
behavior)

Re-authentication is more complex.

I prefer the current text but don't think it would be a problem to
change the SHOULD document for retransmission and discard to a MUST.

I'd object to the change for re-authentication.

--Sam