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

From: Rhys Smith <[email-masked]>
Date: Mon, 4 Mar 2013 16:50:36 +0000

I have no issues with the text as is (when Yoshi's points are included).

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

On 22 Feb 2013, at 23:37, Joseph Salowey (jsalowey) <[email-masked]> wrote:

> 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.
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab