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

From: <[email-masked]>
Date: Thu, 13 Mar 2003 14:21:21 +0200

Mohan, 

At the moment PANA draft doesn't describe a key derivation mechanism for PANA SA from EAP session key. Maybe we need this? You could propose text for this. Especially if the PANA SA consist of two keys, one for each direction (PaC-->PAA and PAA-->PaC). 

- Dan

> -----Original Message-----
> From: ext Mohan Parthasarathy [mailto:[email-masked]]
> Sent: 13 March, 2003 03:49
> To: Alper Yegin; Yoshihiro Ohba
> Cc: Patil Basavaraj (NET/Dallas); [email-masked]
> Subject: RE: WG Last
> Call:draft-ietf-pana-usage-scenarios-04.txt[Correction]
> 
> 
> 
>  
> > 
> > >>> 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: <[email-masked]>
Date: Thu, 13 Mar 2003 14:55:01 +0200

Hi,

Reading Alper's email I noticed that currently the pana draft assumes that the EAP session key is used as it is. So, unless this becomes a problem   we can stick to that?

- Dan

> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: 13 March, 2003 14:42
> To: Forsberg Dan (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> hi dan, 
> hi mohan. 
> if we need a key derivation procedure (assuming it is not 
> done within the
> eap wg) then i would suggest to rely on something existing (instead of
> inventing something new). i am aware of the following key derivation
> procedures: 
> 
> a) "key derivation without a hierarchy"
> 
> the key and some other parameters serve as an input to a prf. each prf
> produces one part of the derived key. the output of a prf is 
> input to the
> next prf. every prf takes the key as input.  
> 
> this approach is for example used by KINK, by IKE, by 
> Kerberos and by the
> secure session key generation proposal by Blumenthal [1].  
> 
> b)  "key derivation with a hierarchy"
> 
> as a difference to the above-described procedure the output 
> of each prf is
> not directly used as part of the derived key. instead it is 
> again input to a
> function f. this function f also uses the key as second 
> input. furthermore
> each function f takes the input of all previously computed 
> prfs as an input.
> 
> this approach is for example used by TLS/SSL and by PKCS #5.  
> 
> ciao
> hannes
> 
> [1]	Blumenthal, U.: "Secure Session Key Generation. 
> Createing PRF from
> MAC Function", <draft-blumenthal-keygen-03.txt>, (work in 
> progress), July,
> 2002. 
> 
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, March 13, 2003 1:21 PM
> > To: [email-masked]; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: WG Last
> > At the moment PANA draft doesn't describe a key derivation 
> > mechanism for PANA SA from EAP session key. Maybe we need 
> > this? You could propose text for this. Especially if the PANA 
> > SA consist of two keys, one for each direction (PaC-->PAA and 
> > PAA-->PaC). 
> > 
> > - Dan
> >