Subject: RE: WG Last Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 12 Mar 2003 17:49:13 -0800

> 
> >>> The mechanisms that are used to turn keying
> >> material produced by
> >>>             the initial authentication method into
> >> link-layer or network-layer
> >>>             ciphers are outside the scope of PANA.
> >>> 
> >>>        Is it outside the scope PANA or PANA WG ? The next
> >> question someone will ask
> >>>        is "how does PANA prevent service theft" ?
> >> 
> >> According to the current charter, defining key distribution, key
> >> agreement or key derivation protocols is out of the scope 
> of PANA.  On
> >> the other hand, the text talks about key derivation mechanisms, not
> >> key derivation protocols, and the mechanisms may be in the
> >> sope of PANA...
> >> 
> > I am confused. I thought the above text talks about how to use the
> > keys derived from the initial authentication in further establishing
> > the SA. It says that it is outside the scope of PANA. In my
> > understanding,
> > 
> > key derivation = deriving keys at the end of authentication 
> from EAP +
> > methods (e.g. EAP keying draft)
> 
> PANA protocol carries EAP, hence whatever EAP and EAP methods 
> provide is
> inherently available to the users of the PANA protocol. What 
> PANA protocol
> does not do is , for example, defininig AVPs etc to specifically carry
> keying material between PaC and PAA.
> 
> > 
> > key distribution = Distribute the above derived keys to EP 
> (PANA will just
> > specify which protocol to use)
> 
> This is outside the scope of "PANA protocol". PANA WG's task 
> is to identify
> at least one such protocol that takes care of the required PAA-EP
> communicaton.
> 
Ok, wrong words. Yes, identify the protocol to use.

> > 
> > key agreement = How to establish an SA between PaC and PAA 
> using the above
> > keys ?
> 
> If the EAP method carried over PANA generates some keying 
> material, this
> material is used to define a "PANA SA". This is a simple SA 
> that binds the
> device ID to some cryptographic key from PAA and PaC's perspective.
> This SA is created at the end of the successful PANA exchange.
> 
I am getting confused with the terminology here. At the end of PANA,
assume you are able to derive some key that is known only to PAA
and PaC (e.g. Master session key mentioned in EAP keying draft).
Are you going to do something further with this key to derive a PANA SA ?
For example, PPP uses ECP (rfc1968) to negotiate algorithms etc. 

> This is not the same SA that EPs need to perform access 
> control, like using
> L2 ciphers or IPsec. PANA SA is used as input to some other 
> mechanisms, like
> IKE, to produce the desired SA, like IPsec SA. Turning PANA 
> SA into access
> control SA is not part of the "PANA protocol". I'm not sure 
> if there is any
> protocol work here, but definitely some guideline doc 
> (informational rfc)
> would be useful. Should PANA WG produce this document? This is an open
> question, comments welcome.....
> 
I think this WG should produce such a document so that PANA can be
used/deployed on shared links. Don't we need an interoperable way of
establishing this SA ? 

> 
> > 
> > If we can clearly specify what is in scope or not, it would 
> be useful.
> > 
> >> What do others think?
> >> 
> > I will try to have a slide as part of my presentation on 
> this topic so that
> > we can get clarified at the meeting.
> 
> Thank you.
> 
> > 
> >>> 
> >>> 4) In section (3.3), towards the end
> >>> 
> >>> A solution like PANA at the network layer may
> >> be adequate if it can
> >>>             specify appropriate authentication methods that
> >> can derive and distribute
> >>>             keys for authentication, integrity and
> >> confidentiality of data traffic
> >>>             either at the link or at the network layer.
> >>> 
> >>>      Again it is not clear what PANA is doing here. And
> >> confidentiality can be removed
> >>>      i think as per the last ietf meeting.
> >> 
> >> I'm not sure which part is not clear in the above text.  Could you
> >> elaborate or provide suggested text?
> >> 
> > The text in itself is fine. But, it goes back to the same 
> question as
> > to whether PANA will provide per-packet integrity, confidentiality ?
> 
> PANA protocol stops where it produces PANA SA.
> 
> Turning PANA SA into access control SA for L2 or L3 needs 
> some guidelines,
> in general. Should PANA WG do this?
> 
> Once you have the access control SA, you go ahead and use it with L2
> ciphers, or IPsec...
> 
See above.

> alper
mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Mar 2003 19:32:24 -0800

> and PaC (e.g. Master session key mentioned in EAP keying draft).

Yes. Here is how we defined PANA SA:

PANA Security Association:
    
       The representation of the trust relation between the PaC and the
       PAA that is created at the end of the authentication phase
       (PH2). This security association includes the device identifier
       of the peer, and a shared key when available.

> Are you going to do something further with this key to derive a PANA SA ?

No, that's  it. PANA SA can be established with that key.

But if the network is going to use IPsec as the per-packet protection after
PANA authentication, it needs IPsec SA. Somehow one needs to transform PANA
SA to IPsec SA using IKE, etc. This transformation is not done by the PANA
protocol.

> For example, PPP uses ECP (rfc1968) to negotiate algorithms etc.

Depending on the network, some L2 cipher negotiation can take place, and
ciphering can be turned on. But these happen all after PANA authentication
is ended, and there is a PANA SA. [assuming we are talking about enabling
ciphering after PANA]

PANA protocol helps these other mechanisms to bootstrap, but its job is
complete as soon as it produces the PANA SA.

makes sense?

alper