eap Mailing List: RE: Issue 218: TLS example

[Joseph Salowey (jsalowey]

Jari Arkko wrote:
> Joseph Salowey wrote:
> 
>>> Method-specific success indications help avoid these
>>> issues. In a method suporting success indications,
>>> a peer willing to accept access does not consider
>>> the authentication successful until receives an
>>> indication that the server is willing to
>>> grant access.
>>> 
>>> In such a method, a server willing to grant access
>>> does not consider the authentication successful
>>> until it receives an indication that the
>>> peer is willing to accept access.
>>> 
>> 
>> [Joe] The two previous paragraphs require the authentication method
>> to perform full authorization in order to implement method-specific
>> success indications.  Protected result indications for authentication
>> methods should synchronize the result of authentication.
>> 
>> "does not consider the authentication successful until it receives
>> and indication that the [peer/server] successfully completed
>> authentication."
> 
> I think your version is the absolute minimum that can be/is
> provided by these indications. Bernard's version on the other
> hand is the absolute maximum that can ever be provided. I
> think the truth lies somewhere in between...  We are also
> walking a fine line between not requiring impossible things
> from implementations but still making it possible to use EAP
> in a reasonable manner in the peer-to-peer case.
> 
> How about this: "...until it receives an indication that the
> peer/server successfully completed authentication. When
> sending such indications, the sender SHOULD verify that
> sufficient authorization exists for granting access, though
> as discussed below this is not always possible."
> 
[Joe] The SHOULD here is really not appropriate. We are talking about an
authentication protocol. How about 

"...until it receives an indication that the
peer/server successfully completed authentication. When
sending such indications, it is often desirable to verify that
sufficient authorization exists for granting access, though
as discussed below this is not always possible."


>>> Success indications may be explicit or implicit.
>>> For example, where a method supports error messages,
>>> an implicit success indication may be defined as the reception of a
>>> specific message without a preceding error message. Failure
>>> indications are typically explicit.
>>> 
>>> As described in Section 4.2.1, a peer silently
>>> discards a Failure packet received at a point where
>>> the method does not explicitly permit this to be sent.
>>> For example, a method providing its own error
>>> messages might require the peer to receive an
>>> an error message prior to accepting a Failure packet.
>>> While this may be useful for debugging purposes,
>>> it will typically add a round-trip to the method.
>>> 
>>> Where result indications are authenticated,
>>> integrity and replay protected, it is possible to
>>> to address spoofing vulnerabilities.  Since protected
>>> result indications require use of a key for per-packet
>>> authentication and integrity protection, methods supporting
>>> protected result indications MUST also support the "key
>>> derivation", "mutual authentication" "integrity protection" and
>>> "replay protection" claims. However, since errors can occur prior
>>> to key derivation, it is typically not possible to protect all
>>> failure indications. 
>>> 
>>> While protected result indications may enable synchronization
>>> between the peer and the server, this does not guarantee that the
>>> peer and authenticator will be synchronized or that timeouts will
>>> not occur. For example, the EAP server may not be aware of an
>>> authorization decision made by a AAA proxy; or the EAP server may
>>> grant access, but the authenticator may be unable to provide it due
>>> to a temporary lack of resources. In these situations,
>>> synchronization can only be achieved via lower layer result
>>> indications. 
>>> 
>> 
>> [Joe] "Protected protected result indications may enable
>> synchronization of the authentication result between the peer and the
>> server, this does not guarantee that the that the peer and the
>> authenticator will be synchronized to authorize access."
> 
> Yes, better. Thanks.
> 
> --Jari