http://blog.gmane.org/gmane.ietf.pana hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.pana/879 <pre>I got a question from my colleague about meaning of "PRF key" in the following text in Section 8.5: " 1. The PaC and the PAA each are likely to be able to compute a random nonce (according to [RFC4086]). The length of the nonce has to be 1/2 the length of the PRF key (e.g., 10 octets in the case of HMAC-SHA1). 2. The PaC and the PAA each are not trusted with regard to the computation of a random nonce (according to [RFC4086]). The length of the nonce has to have the full length of the PRF key (e.g., 20 octets in the case of HMAC-SHA1). " As far as I remember, "PRF key" means "output block of the negotiated pseudo-random function used in prf+". So HMAC-SHA1 is prf, the output block length is 20 octets. Please let me know if you interpret "PRF key" in the above text in other ways. Best Regards, Yoshihiro Ohba </pre> Yoshihiro Ohba 2013-01-21T01:27:10 http://comments.gmane.org/gmane.ietf.pana/877 <pre>Dear all, As you may know, University of Murcia (Spain) published a PANA source code named OpenPANA to sourceforge. We have updated the source code to support PANA Relay (PRE) RFC 6345 and improved previous OpenPANA version. The PRE implementation is also written in C language. The link where you can download the project is http://openpana.sourceforge.net/ It is also worth noting that we have developed a PANA client (PaC) implementation in Contiki SO (PANATIKI) that can be downloaded from http://sourceforge.net/projects/openpana/files/panatiki-0.1.tar.gz/download It has been tested in Jennic JN5139 Wireless Microcontroller. Any comment and feedback is welcome. Please contact the mailing list associated to the project to obtain any help openpana-users&lt; at &gt;lists.sourceforge.net Best regards and many thanks. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia -</pre> Rafa Marin Lopez 2012-05-08T14:06:13 http://comments.gmane.org/gmane.ietf.pana/858 <pre> The following errata report has been submitted for RFC5191, "Protocol for Carrying Authentication for Network Access (PANA)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5191&amp;eid=2997 -------------------------------------- Type: Technical Reported by: Yoshihiro Ohba &lt;yoshihiro.ohba&lt; at &gt;toshiba.co.jp&gt; Section: 8.4 Original Text ------------- The Key-Id AVP (AVP Code 4) is of type Integer32 and contains an MSK identifier. Corrected Text -------------- The Key-Id AVP (AVP Code 4) is of type Unsigned32 and contains an MSK identifier. Notes ----- The Correct Text will be consistent with the following text in Section 5.3, "The Key-Id AVP is of type Unsigned32..." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the </pre> RFC Errata System 2011-10-14T06:52:00 http://comments.gmane.org/gmane.ietf.pana/853 <pre>My colleague Tanaka-san found out a potential error in RFC 6345 (PANA relay). The following paragraph in Section 2: " When the PRE receives the PRY message, it retrieves the PAA- originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from and PaC-Information AVPs. The PAA-originated PANA message is sent to the PaC's IP address with the source UDP port number set to the PANA port number (716) and the destination UDP port number set to the UDP port number contained in the Relayed-Message AVP. " should read: " When the PRE receives the PRY message, it retrieves the PAA- originated PANA message from the Relayed-Message AVP and the PaC's IP address and UDP port number from and PaC-Information AVPs. The PAA-originated PANA message is sent to the PaC's IP address with the source UDP port number set to the PANA port number (716) and the destination UDP port number set to the UDP port number contained in the PaC-Information AVP. " (s/Relayed-Message/PaC-Information/ i</pre> Yoshihiro Ohba 2011-10-13T13:50:02 http://comments.gmane.org/gmane.ietf.pana/850 <pre>Dear all, I hope this information is useful for you. I am pleased to announce that University of Murcia (Spain) has published a PANA source code named OpenPANA to sourceforge. The implementation is written in C language and it is able to interact with a backend RADIUS server. The link where you can download the project is http://openpana.sourceforge.net/ Please contact the mailing list associated to the project to obtain any help openpana-users&lt; at &gt;lists.sourceforge.net Best regards and many thanks. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa&lt; at &gt;um.es ------------------------------------------------------- _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Rafa Marin Lopez 2011-09-29T11:41:21 http://comments.gmane.org/gmane.ietf.pana/836 <pre>We have received the following question from IANA. Since the 'R' (Request) bit is not set for PANA-Relay, I think it should be filled with "Ans" (not "Req"). BTW, I've found that PCI, for which the 'R' (Request) bit is not set, is filled with "Req" in the IANA registry. I think this should have been filled with "Ans" as well. Any opinions? Yoshihiro Ohba -------- Original Message -------- Subject: [IANA #454490] Last Call: &lt;draft-ohba-pana-relay-03.txt&gt; (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard Date: Wed, 08 Jun 2011 20:37:04 +0000 From: Amanda Baber via RT &lt;drafts-lastcall&lt; at &gt;iana.org&gt; Reply-To: drafts-lastcall&lt; at &gt;iana.org CC: paduffy&lt; at &gt;cisco.com, samitac2&lt; at &gt;gmail.com, robert.cragie&lt; at &gt;gridmerge.com, yoshihiro.ohba&lt; at &gt;toshiba.co.jp, alper.yegin&lt; at &gt;yegin.org, iesg&lt; at &gt;ietf.org IESG: IANA has reviewed draft-ohba-pana-relay-03.txt and has the following comments: IANA has questions about the IANA Actions in this document. IANA understands that, upon approval of this </pre> Yoshihiro Ohba 2011-06-09T03:46:31 http://comments.gmane.org/gmane.ietf.pana/825 <pre>There is inconsistency about Key-Id data type as follows: In Section 5.3, "The Key-Id AVP is of type Unsigned32 ..." In Section 8.4, "The Key-Id AVP (AVP Code 4) is of type Integer32 ..." The text in Section 8.4 seems incorrect, and should be corrected to: "The Key-Id AVP (AVP Code 4) is of type Unsigned32 ..." Regards, Yoshihiro Ohba </pre> Yoshihiro Ohba 2011-05-12T07:44:21 http://comments.gmane.org/gmane.ietf.pana/822 <pre>I would like to note that PANA relay (and RFC 5191 of course) is being implemented by a couple of ZigBee vendors and showing successful interoperability in ZigBee IP mesh networking environment. I guess this is something people on this ML wanted to know. Regards, Yoshihiro Ohba </pre> Yoshihiro Ohba 2011-02-15T16:07:03 http://comments.gmane.org/gmane.ietf.pana/821 <pre>We have updated pana-relay draft, incorporating all received comments and associated discussions. Thanks, Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification for draft-ohba-pana-relay-03 Date: Thu, 03 Feb 2011 23:13:23 -0800 (PST) From: IETF I-D Submission Tool &lt;idsubmission&lt; at &gt;ietf.org&gt; To: yoshihiro.ohba&lt; at &gt;toshiba.co.jp CC: paduffy&lt; at &gt;cisco.com, samitac2&lt; at &gt;gmail.com, robert.cragie&lt; at &gt;gridmerge.com, alper.yegin&lt; at &gt;yegin.org A new version of I-D, draft-ohba-pana-relay-03.txt has been successfully submitted by Yoshihiro Ohba and posted to the IETF repository. Filename: draft-ohba-pana-relay Revision: 03 Title: Protocol for Carrying Authentication for Network Access (PANA) Relay Element Creation_date: 2011-02-04 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) wher</pre> Yoshihiro Ohba 2011-02-08T00:24:41 http://comments.gmane.org/gmane.ietf.pana/815 <pre>Resending to the list... -----Original Message----- From: Alper Yegin [mailto:alper.yegin&lt; at &gt;yegin.org] Sent: Monday, December 13, 2010 10:32 AM To: 'Yoshihiro Ohba'; 'Alan DeKok' Cc: 'secdir&lt; at &gt;ietf.org'; 'draft-ohba-pana-relay&lt; at &gt;tools.ietf.org'; 'margaretw42&lt; at &gt;gmail.com'; 'Ralph Droms'; 'paduffy&lt; at &gt;cisco.com'; 'samitac&lt; at &gt;ipinfusion.com'; 'robert.cragie&lt; at &gt;gridmerge.com'; 'pana&lt; at &gt;ietf.org' Subject: Token (was RE: Secdir review of draft-ohba-pana-relay) Alan, Arbitrary traffic cannot pass the validation on the PaC, as the sequence numbers need to match. And there is also state machine match needed. PaC's is in certain state and would not react to any arbitrary message unless the message is expected in the current state. Alper </pre> Alper Yegin 2010-12-14T08:40:41 http://comments.gmane.org/gmane.ietf.pana/814 <pre>Resending to the list..... -----Original Message----- From: Alper Yegin [mailto:alper.yegin&lt; at &gt;yegin.org] Sent: Monday, December 13, 2010 10:28 AM To: 'Yoshihiro Ohba'; 'Alan DeKok' Cc: 'secdir&lt; at &gt;ietf.org'; 'draft-ohba-pana-relay&lt; at &gt;tools.ietf.org'; 'margaretw42&lt; at &gt;gmail.com'; 'Ralph Droms'; 'paduffy&lt; at &gt;cisco.com'; 'samitac&lt; at &gt;ipinfusion.com'; 'robert.cragie&lt; at &gt;gridmerge.com'; 'pana&lt; at &gt;ietf.org' Subject: PRE enforcing message validity (was RE: Secdir review of draft-ohba-pana-relay) Hi Alan, Thank you for the review. Is the concern that a rogue PRE injecting bogus PANA messages towards the PaC, or a legitimate PRE relaying bogus PANA messages injected by some rogue PAA? Why not let the PaC deal with this? It already performs such checks. Alper </pre> Alper Yegin 2010-12-14T08:40:30 http://comments.gmane.org/gmane.ietf.pana/787 <pre>Hi All, As part of asking the Security Directorate to review draft-ohba-pana- relay-02.txt, I reviewed the Security Considerations section and tried to determine how/if this relay changes the security model for PANA. As I understand it, the original PANA protocol relied on return routability... We didn't worry about address spoofing, because the credentials were returned to the address they were meant for, meaning that only an on-link (or on path? -- but we didn't allow a path originally) attacker could spoof a client address and see the response. With introduction of relay code on the PAA, any node can pretend to be a PRE and get credentials for any other node. This isn't mentioned in the Security considerations section, but it is potentially significant. So, there might be a need for the PAA to authorize the PRE before responding to messages from it. If there is some reason why you don't believe the PAA needs to authorize the PRE, you would (at the very least) need to explain </pre> Margaret Wasserman 2010-11-19T20:28:22 http://comments.gmane.org/gmane.ietf.pana/786 <pre>Hi Pana Relay Authors, I've been asked to shepherd draft-ohba-pana-relay-02.txt for RFC publication as a standards track document. As part of that process, I am required to perform my own review of the document before doing a document write-up. During my review, I found several issues that should be resolved before this draft is published. I'll start with a question: Before I read this draft, I was under the impression that the Pana Relay would forward Pana messages between an unmodified Pana Client (PAC) and an unmodified Pana Authentication Agent (PAA), allowing Pana to be used on networks, such as 6lowpan networks, that have multi-hop links. However, the mechanism in this draft requires modifications to the PAA to support a new message type for relayed messages. Are the expected users of this technology aware that an updated PAA will be required? Is there reason to believe that updated PAAs will be available? Now onto issues with the document text... SUBSTANTIVE ISSUES: S1) It appears that this </pre> Margaret Wasserman 2010-11-19T17:50:52 http://comments.gmane.org/gmane.ietf.pana/784 <pre>A new draft extending PANA has been published: "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", draft-ohba-pana-relay-02. This document will be advanced to the IESG as an AD-sponsored individual submission. As part of the process, I'd like to get external review of the document. Please read the draft and reply to pana&lt; at &gt;ietf.org with any comments. Thanks. - Ralph </pre> Ralph Droms 2010-11-16T10:46:11 http://comments.gmane.org/gmane.ietf.pana/783 <pre>Dear all, I am pleased to announce that Toshiba published PANA source code written in C language (CPANA) to sourceforge. The project webpage is http://cpana.sourceforge.net/. The best way to get help with its software is by sending email to its mailing list at cpana-users&lt; at &gt;lists.sourceforge.net. Hope this helps, Yoshihiro Ohba Toshiba Corporation </pre> Yoshihiro Ohba 2010-08-23T05:43:07 http://comments.gmane.org/gmane.ietf.pana/781 <pre> Please see below for the revised version of this I-D. -----Original Message----- From: i-d-announce-bounces&lt; at &gt;ietf.org [mailto:i-d-announce-bounces&lt; at &gt;ietf.org] On Behalf Of Internet-Drafts&lt; at &gt;ietf.org Sent: Tuesday, March 09, 2010 1:00 AM To: i-d-announce&lt; at &gt;ietf.org Subject: I-D Action:draft-yegin-pana-unspecified-addr-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address Author(s) : A. Yegin, et al. Filename : draft-yegin-pana-unspecified-addr-01.txt Pages : 9 Date : 2010-03-08 This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-pana-unspecified-addr-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MI</pre> Alper Yegin 2010-03-09T08:45:59 http://comments.gmane.org/gmane.ietf.pana/774 <pre> Comments are welcome. -----Original Message----- From: i-d-announce-bounces&lt; at &gt;ietf.org [mailto:i-d-announce-bounces&lt; at &gt;ietf.org] On Behalf Of Internet-Drafts&lt; at &gt;ietf.org Sent: Monday, March 01, 2010 3:00 PM To: i-d-announce&lt; at &gt;ietf.org Subject: I-D Action:draft-yegin-pana-unspecified-addr-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address Author(s) : A. Yegin, Y. Ohba Filename : draft-yegin-pana-unspecified-addr-00.txt Pages : 9 Date : 2010-03-01 This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-pana-unspecified-addr-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader impleme</pre> Alper Yegin 2010-03-01T14:47:31 http://comments.gmane.org/gmane.ietf.pana/772 <pre>_______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Georgopoulos, Panagiotis 2010-02-02T15:36:29 http://comments.gmane.org/gmane.ietf.pana/770 <pre>Hi, We have written a draft to update RFC 5191 IANA rules, relaxing them a bit. This makes it possible to process drafts such as the preauth draft, which is experimental but allocates a bit in the header. It would be great to get reviews of this draft. Here's the URL: http://www.ietf.org/id/draft-arkko-pana-iana-00.txt Jari </pre> Jari Arkko 2010-02-01T05:26:32 http://comments.gmane.org/gmane.ietf.pana/767 <pre>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : Application of PANA framework to DSL networks Author(s) : L. Morand, et al. Filename : draft-ietf-pana-panaoverdsl-01.txt Pages : 25 Date : 2010-01-25 This document provides guidelines for PANA deployment over DSL access networks. The document specifically describes the introduction of PANA in DSL networks migrating from a traditional PPP access model to a pure IP-based access environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-panaoverdsl-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. __________________________</pre> Internet-Drafts< at >ietf.org 2010-01-25T14:30:02 http://comments.gmane.org/gmane.ietf.pana/765 <pre>Changes from the previous version: - Changed the intended status to Experimental. - Made clarification on CPAA discovery to provide IP address of CPAA as the output. - Made 802.21 Information Service an optional CPAA discovery mechanism. Regards, Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification - draft-ietf-pana-preauth-08.txt Date: Mon, 14 Dec 2009 21:45:02 -0800 (PST) From: Internet-Draft&lt; at &gt;ietf.org To: pana-chairs&lt; at &gt;tools.ietf.org, draft-ietf-pana-preauth&lt; at &gt;tools.ietf.org, jari.arkko&lt; at &gt;piuha.net New version (-08) has been submitted for draft-ietf-pana-preauth-08.txt. http://www.ietf.org/internet-drafts/draft-ietf-pana-preauth-08.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-pana-preauth-08 IETF Secretariat. </pre> Yoshihiro Ohba 2009-12-15T06:42:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.pana