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

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 12 Mar 2003 11:34:47 -0800

> 
> Hi Mohan,
> 
> Thanks for reviewing the draft and sorry for my delayed response.  
> Please see my comments in line.
> 
> On Fri, Mar 07, 2003 at 09:25:17AM -0800, Mohan Parthasarathy wrote:
> > 
> > The document looks good except for these minor issues.
> > 
> > 1) In section 2, Problem statement
> > 
> > 	"Access networks usually require clients to go through 
> an authentication and
> >        authorization process unless physical security is 
> used as a substitute".
> > 
> >    In section 3.1, PANA with physical layer security,
> >    
> >       "In the networks where a certain degree of security 
> is provided at physical
> >        layer, authenticating the client is still essential 
> since physical layer
> >        does not provide information on the client..."
> > 
> >    It is not a major thing. But it was a bit confusing to read.
> 
> I see.  Perhaps we can remove "unless physical security is used as a
> substitute" from the sentense in section 2.

Ok.

> 
> > 
> > 2) In section (2),
> >  
> > 	    Initial client authentication needs 
> >           to be bound to subsequent traffic to prevent 
> spoofing and hijacking
> >           of data packets. 
> > 
> >       What do you mean by hijacking of data packets ? 
> 
> It means service theft.  So how about the following?
> 
>    Initial client authentication needs to be bound to subsequent
>    traffic to prevent spoofing of data packets and resulting service
>    theft.
> 
Sounds good.

> > 
> > 
> > 3) In section (2), following 2 sentences are still confusing me.
> > 
> > 		PANA is only responsible for carrying EAP and 
> it should not have
> >             to deal with the keying material.Once the 
> keying material is present
> > 
> >        You talked about the need for generating key 
> material a few lines back.
> >        Here we are saying PANA will not do it. I think you 
> may want to say, that
> >        EAP will be used to generate the keying materail 
> (refer that EAP-keying draft).
> 
> I think the following already mentions the use of EAP to generate the
> keying material:
> 
>    "The task of generating and distributing such keying 
> material can be
>    accomplished by various authentication methods carried by EAP."
> 
> Isn't it enough?
> 
I think it is sufficient.

> > 
> > 		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)

key distribution = Distribute the above derived keys to EP (PANA will just
specify which protocol to use)

key agreement = How to establish an SA between PaC and PAA using the above keys ?

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.

> > 
> > 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 ?

> > 
> > 5) In section 3.6, Limited Free Access,
> > 
> > 		On the other hand, access to further services 
> or sites using such local
> >             networks requires authentication and 
> authorization.  If users want such
> >             services, the access network can detect that 
> attempt and initiate
> >             authentication.  This also allows the network 
> to initiate the 
> >             authentication whenever appropriate.
> > 
> >       I think the last sentence can be modified to "This 
> also allows the network to
> >       initiate the authentication to authenticate the 
> client whenever appropriate".
> >       You may ignore this if it is redundant. But when i 
> read it first time, it was
> >       a bit confusing.
> 
> OK.
> 
> Thanks,
> Yoshihiro Ohba

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Mar 2003 14:53:17 -0800

> 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.

> 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.

> key agreement = How to establish an SA between PaC and PAA using the above

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.

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.....

> we can get clarified at the meeting.

Thank you.

> 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...

alper