Authentication Policy

This API supports a generic and flexible way of supporting authentication policies, which is particulary useful in an environmment in which multiple authentication methods are used.

An authentication policy is represented as a binary tree in which each node corresponds to an authentication method. If a node is not a leaf node, it has two branches each corresponds to success or failure operation. A node in a policy tree is refered to as policy element (PE). An example of authentication policy representation is shown below.

                             s        s
                   --> A(1) --> B(2) --> S1
                       |        |     f        s
                       |        +------> C(3) --> S2
                       |                 |     f
                       |                 +------> F
                       |     f        s        s
                       +------> D(2) --> E(3) --> S3
                                |     f  |     f
                                |        +------> S4
                                |
                                +------> F

In the above example, a policy tree is composed of five PEs, namely A, B, C, D, E, S1, S2, S3, S4 and F. Branches tagged with 's' and 'f' of each PE are traversed when the result of the corresponding authentication type is successful and failure, respectively. PEs S1, S2, S3, S4 and F are leaf nodes corresponding to final success and final failure, respectively. Each final success leaf can be bound to a distinct authorization type. Each PE is bound to a single authentication type represented by the number in round brackets.

The above policy tree constitutes an ordered authentication policy. For example, PE B is never examined before PE A. PE B is never examined if PE A fails. An unordered authentication policy can be rearrenged to an ordered authentication policy. The ordered policy in the above example is an rearrengement of an unordered policy which succeeds if any two authentication types in the set of authentication types 1, 2 and 3 succeeds.

Both Authenticator and Peer can have a distinct authentication policy tree. During the EAP conversation, the two peering policy trees are traversed based on Request/Response message exchange in which the Authenticator proposes a specific authentication type and the Peer replies with a Response with the proposed authentication type if the proposed type is supported by the Peer, otherwise it replies with a Nak with a list of supported authentication types in the order of preference. In the latter case, the Nak'ed PE must be considered failure in the Authenticator policy, and the list contained in the Nak must be used for further traversing the failure branch(es) of the policy subtree until the traversal encounters a PE that matches one of the authentication type(s) in the list contained in the Nak or a final success/failure leaf.

---