eap Mailing List: Re: PANA and EAP keying framework

[Jari Arkko (jari.arkko]

Yoshi, Bernard,


> It would be useful to add some
> description on how PANA handle the caching of EAP keying material and
> the generation of transient session keys.

Yes,this would be useful. Thanks for the input.

> >      TSKs are generated using a Secure Association Protocol
>
>
> Can you elaborate on this?  If the TSKs are generated via an IKE DH 
> exchange, with the MSK used only for authentication (as in  IKEv2/EAP) 
> then the TSKs are not dependent on the MSK and PFS is possible, right?

Yes.  But PANA does not mandate IKE, it could also run with some 
yet-to-be-designed
L2 mechanism that does not offer PFS.

> >      between the peer and and authenticator port
>
>
> Not sure I understand this.   The SAP exchange is between the peer and 
> authenticator, not between specific ports.  However, a result of the 
> SAP exchange can be derivation of TSKs which are bound to specific ports.

In PANA, the authenticator can be "distributed", i.e., consist of the
point where the EAP/AAA handling happens, and multiple enforcement
points where the L2/L3 crypto for the actual session is terminated.

Anyway, the term "port" is somewhat confusing here... not well
defined.

> >      Point), where both link-layer specific key exchange protocols and
> >      IKE can be used as the Secure Association Protocol depending on
> >      whether link-layer ciphering or IPsec is used between the peer
> >      and the authenticator port.
>
>
> What is a "link-layer specific key exchange protocol"?  Are we talking 
> about existing SAPs such as 802.11i 4-way handshake, or something else?

802.11i is mentioned as a specific example in the documents,
but I don't know if the details of how to use PANA with it
are written down anywhere. The details about IKE usage
are in draft-ietf-pana-ipsec.

It might be an idea to explain the pana/ike case here, and
not the open-ended other possible scenarios.

> >      The key scope and lifetime of the
> >      TSKs are communicated from the authenticator to the peer.
>
>
> How?  IKE does not define explicit lifetimes, nor does it care about 
> key scope because it doesn't support caching.

Identifiers of the parties and session are delivered to the enforcement
point. The client also knows them. Lifetime can be known by the
enforcement point and locally enforced, but as you note it can not
be communicated to the client under IKEv2.

> >      The key scope is specified as a list of device identifiers of the
> >      Enforcement Points.
>
>
> This doesn't make sense where IKE is used as the SAP unless we are 
> talking about MOBIKE (which can move SAs between addresses).

According to draft-ietf-pana-ipsec, from the enforcement
point's point of view, the scope is exactly one EP.

--Jari