Re: [Pana] Preliminary pana-pana draft (13a)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pana] Preliminary pana-pana draft (13a)



Hi Rafa,

Thank you for the review.  Please see my comment below.

On Wed, Nov 29, 2006 at 02:36:30AM +0100, Rafa Marin Lopez wrote:
> Hi Yoshi,Alper, all
> 
> I have been reviewing the doc.In general, it is ok for me.
> 
> Only some two minor comments:
> 
> Page 13:
> 
> "The MSK and the PANA session MUST be deleted
>   immediately after the PANA-Bind message exchange."
> 
> I think I missed something...could anybody point me where this was 
> discussed to understand the reason behind? or is it a mistake?
> 
> Initially i think PANA session should not be removed. On the other hand, 
> with this text PANA does not allow MSK caching. Taking into account all 
> references to bootstrapp security
> has been removed it seems coherent because MSK won't be used further. 
> However, i was wondering why this limitation.

Note that the above behavior is in the context of the following case:

"
   There is a case where EAP authentication succeeds with producing an
   EAP Success message but network access authorization fails due to,
   e.g., authorization rejected by a AAA or authorization locally
   rejected by the PAA.  
"

This means, if authorization fails then the PANA session must be
deleted even if the EAP authentication has succeeded.  So the current
text should be ok.

> 
> 
> Section 4.4. says :
> 
> "A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-
>   Auth-Answer messages."
> 
> However , Figure 9 (table) has 0-1 for PAR/PAN
> 
> I guess it should be 1 taking into account the text above (on the other 
> hand, that Nonce AVP would not be needed if EAP method is not able to 
> generate cryptographic material)

It is true that Nonce AVP will not be used if MSK is not generated.
However, since PANA layer should not know which EAP method is in use
or is able to generate MSK, the only way is to mandate Nonce AVP in
the first PAR/PAN exchange.

The occurence table stating that Nonce AVP is 0-1 for PAR/PAN is
correct.  This is because Nonce AVP is carried only in the first
PAR/PAN exchange in authentication and authorization phase and
re-authentication phase, and it is not carried in other PAR/PAN
exchanges.

Yoshihiro Ohba


> 
> Best Regards.
> 
> Alper Yegin wrote:
> 
> >Thank you Yoshi.
> >
> >Let's set a timer. PANA WG members: Please review and register your 
> >feedback
> >by the end of Nov 28 (one week). 
> >
> >Alper
> >
> >
> >
> >
> >
> >
> >
> > 
> >
> >>-----Original Message-----
> >>From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> >>Sent: Sunday, November 19, 2006 10:39 AM
> >>To: pana at ietf.org
> >>Subject: [Pana] Preliminary pana-pana draft (13a)
> >>
> >>is available at:
> >>
> >>http://www.panasec.org/docs/editing/pana-spec.html
> >>
> >>(Now we get 17 pages reduction.)
> >>
> >>Please do sanity check to make sure that all resolutions discussed in
> >>IETF67 and over mailing list are reflected appropriately.  Diff from
> >>revision 12 is also available.
> >>
> >>As soon as sanity check is done, I will submit a new revision (13)
> >>which is to be used for IETF last call.
> >>
> >>Regards,
> >>Yoshihiro Ohba
> >>
> >>_______________________________________________
> >>Pana mailing list
> >>Pana at ietf.org
> >>https://www1.ietf.org/mailman/listinfo/pana
> >>   
> >>
> >
> >
> >_______________________________________________
> >Pana mailing list
> >Pana at ietf.org
> >https://www1.ietf.org/mailman/listinfo/pana
> >
> >
> > 
> >
> 
> 
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Depto. Ing. de la Info. y las Comunicaciones
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34968398501    e-mail: rafa at dif.um.es
> ------------------------------------------------------
> 
> 

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.