http://permalink.gmane.org/gmane.ietf.pana hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.pana/880 <pre>Yoshi, I think your interpretation is correct, as the "e.g." examples confirm. Alper On Jan 21, 2013, at 3:27 AM, Yoshihiro Ohba wrote: </pre> Alper Yegin 2013-01-24T09:21:52 http://permalink.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://permalink.gmane.org/gmane.ietf.pana/878 <pre>FYI... Begin forwarded message: _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Alper Yegin 2012-11-14T08:18:25 http://permalink.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://permalink.gmane.org/gmane.ietf.pana/876 <pre>I have posted a new revision with changes due to Tanaka-san's comments in place. Please review and provide any further feedback to the list. Thank you Robert -------- Original Message -------- Subject: New Version Notification for draft-yegin-pana-encr-avp-02.txt Date: Tue, 10 Apr 2012 03:45:04 -0700 From: internet-drafts&lt; at &gt;ietf.org To: robert.cragie&lt; at &gt;gridmerge.com CC: alper.yegin&lt; at &gt;yegin.org A new version of I-D, draft-yegin-pana-encr-avp-02.txt has been successfully submitted by Robert Cragie and posted to the IETF repository. Filename: draft-yegin-pana-encr-avp Revision: 02 Title: Encrypting PANA AVPs Creation date: 2012-04-10 WG ID: Individual Submission Number of pages: 9 Abstract: This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form. The IETF Secretariat _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/l</pre> Robert Cragie 2012-04-10T10:48:37 http://permalink.gmane.org/gmane.ietf.pana/875 <pre>Tanaka-san, Thank you for your comments. I have responded inline, bracketed by &lt;RCC&gt;&lt;/RCC&gt;. Robert On 26/03/2012 7:00 AM, Yasuyuki Tanaka wrote: &lt;RCC&gt;Agreed, good catch.&lt;/RCC&gt; &lt;RCC&gt;Agreed.&lt;/RCC&gt; &lt;RCC&gt;Agreed. It was chosen at 3 to be consistent with the use of CCM in the proposed TLS cipher suites.&lt;/RCC&gt; &lt;RCC&gt;That is correct. I will include the example as given.&lt;/RCC&gt; _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Robert Cragie 2012-04-10T10:30:19 http://permalink.gmane.org/gmane.ietf.pana/874 <pre>Hi, I've read the draft and I have four comments. Please see them below. Best, Yasuyuki Tanaka --------------------------------------------------------------------- (1) Section 3 I found a typo in the last sentence. &gt; The length of PANA_ENCR_KEY depends on the integrity algorithm in &gt; use. should be The length of PANA_ENCR_KEY depends on the *encryption* algorithm in use. --------------------------------------------------------------------- (2) Section 4 I've not found text about key size of AES to be used for AES_CTR. Probably 128-bit is assumed. It would be better to clarify the key size to be used for the algorithm and to use "AES128_CTR" or something instead of "AES_CTR". --------------------------------------------------------------------- (3) Section 4 The definition of "q" is different between the draft and NIST SP800-38C. In this draft, "q" is defined as "octet length of message length field." But in NIST SP800-38C, "q" is defined as "The octet length of the binary represe</pre> Yasuyuki Tanaka 2012-03-26T06:00:31 http://permalink.gmane.org/gmane.ietf.pana/873 <pre>I would like to move this forward so I am soliciting any comments from the PANA mailing list. Thanks Robert -------- Original Message -------- Subject: New Version Notification for draft-yegin-pana-encr-avp-01.txt Date: Wed, 04 Jan 2012 01:53:07 -0800 From: internet-drafts&lt; at &gt;ietf.org To: alper.yegin&lt; at &gt;yegin.org CC: robert.cragie&lt; at &gt;gridmerge.com, alper.yegin&lt; at &gt;yegin.org A new version of I-D, draft-yegin-pana-encr-avp-01.txt has been successfully submitted by Alper Yegin and posted to the IETF repository. Filename: draft-yegin-pana-encr-avp Revision: 01 Title: Encrypting PANA AVPs Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 8 Abstract: This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form. The IETF Secretariat _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Robert Cragie 2012-03-16T11:04:49 http://permalink.gmane.org/gmane.ietf.pana/872 <pre>OK, fine, let's do that. On Feb 13, 2012, at 11:41 AM, Yoshihiro Ohba wrote: </pre> Alper Yegin 2012-02-13T14:22:48 http://permalink.gmane.org/gmane.ietf.pana/871 <pre>The behavior I mentioned is stated in RFC 5191: " I (IP Reconfiguration) If set, it indicates that the PaC is required to perform IP address reconfiguration after successful authentication and authorization phase to configure an IP address that is usable for exchanging data traffic across EP. This bit is set by the PAA only for PANA-Auth-Request messages in the authentication and authorization phase. For other messages, this bit MUST be cleared. " I think the right thing is to just refer to RFC 5191 for the behavior iwth the 'I' bit set. Yoshihiro Ohba (2012/02/13 18:01), Yoshihiro Ohba wrote: </pre> Yoshihiro Ohba 2012-02-13T09:41:30 http://permalink.gmane.org/gmane.ietf.pana/870 <pre>Forgot to include pana mailing list.. -------- Original Message -------- Subject: Re: [Pana] I-D Action: draft-yegin-pana-unspecified-addr-05.txt Date: Mon, 13 Feb 2012 17:52:36 +0900 From: Yoshihiro Ohba &lt;yoshihiro.ohba&lt; at &gt;toshiba.co.jp&gt; To: Alper Yegin &lt;alper.yegin&lt; at &gt;yegin.org&gt; (2012/02/09 18:11), Alper Yegin wrote: (snip) I have been interpreting the original text as setting 'I' bit for all PAR messages sent by the PAA in the authentication and authorization phase and clearing the bit for subsequent PAR messages. With this behavior, the PAA can set the 'I' bit from the very first PAR message and the PaC can immediately stop PANA authentication if the PaC does not expect IP address update. I think we need a bit more discussion on this. Yoshihiro Ohba </pre> Yoshihiro Ohba 2012-02-13T09:01:45 http://permalink.gmane.org/gmane.ietf.pana/869 <pre>Alper, I have a second thought. Probably there is no use case for PANA re-authentication phase with the use of unspecified IPv4 address because the PaC is expected to obtain a specified IPv4 address after successful PANA authentication phase. So I think we don't need to consider AUTH AVP for the max message computation. Yoshihiro Ohba (2012/02/10 15:34), Alper Yegin wrote: </pre> Yoshihiro Ohba 2012-02-13T08:59:02 http://permalink.gmane.org/gmane.ietf.pana/868 <pre> I think you are right. Alper </pre> Alper Yegin 2012-02-10T06:34:08 http://permalink.gmane.org/gmane.ietf.pana/867 <pre> In that logic, the max message would be a PAR in re-authentication phase where an EAP-Paylaod AVP carrying an EAP method and additionally an AUTH AVP. Yoshihiro Ohba </pre> Yoshihiro Ohba 2012-02-09T18:26:40 http://permalink.gmane.org/gmane.ietf.pana/866 <pre> OK. Right. Nevertheless, the max message would be reached with the EAP-carrying PAR messages, like you say. Even though there is not limit on the number of *-Algorithms, it'd be a reasonable number not to cause the message going beyond an EAP-carrying PAR message in size. Alper </pre> Alper Yegin 2012-02-09T12:39:15 http://permalink.gmane.org/gmane.ietf.pana/865 <pre>Hello, &gt; The largest PANA message is possibly not the very first PAR &gt; from the PAA (unlike the current draft states). Such a PAR can &gt; be carrying a EAP-Request/Identity, hence not really be caring &gt; a minimum EAP MTU size. A subsequent PAR can be carrying &gt; that (and it'd not have the Integrity-Algorithm, PRF-Algorithm, &gt; and Token AVPs). &gt; &gt; Are you using the same reasoning for your above suggestion? Yes. To shorten a PANA Message, we can send an EAP-Payload AVP in another PANA Message. Strictly speaking, RFC 5191 has no upper limit on the number of PRF-Algorithm AVPs and Integrity-Algorithm AVPs which are contained in a PAR. The size of a PANA message might be the maximum size of the UDP data... Is this correct? [Figure 4, RFC 5191] The table uses the following symbols: 0 The AVP MUST NOT be present in the message. 0-1 Zero or one instance of the AVP MAY be present in the message. It is considered an error if there is more than one instance of the AVP. </pre> Yasuyuki Tanaka 2012-02-09T11:45:57 http://permalink.gmane.org/gmane.ietf.pana/864 <pre>Hello, Thank you for the review and feedback. On Feb 9, 2012, at 7:44 AM, Yasuyuki Tanaka wrote: OK. Let us consider that. I think this is an ambiguity with the RFC 5191. PAR with 'C' bit makes sense. We are trying to find the the size of the largest PANA message. The largest PANA message is possibly not the very first PAR from the PAA (unlike the current draft states). Such a PAR can be carrying a EAP-Request/Identity, hence not really be caring a minimum EAP MTU size. A subsequent PAR can be carrying that (and it'd not have the Integrity-Algorithm, PRF-Algorithm, and Token AVPs). Are you using the same reasoning for your above suggestion? Alper </pre> Alper Yegin 2012-02-09T09:11:57 http://permalink.gmane.org/gmane.ietf.pana/863 <pre>Hi all, I have four comments about the draft. I put them at the bottom of this mail. Please see them. Best, Yasuyuki Tanaka --------------------------------------------------------------------- (1) Page 4, Paragraph 1 It would be helpful to add text about the source port number and the destination port number of the PCI as below. [edited] Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying a Token AVP that contains a random value generated by the PaC. ! The source IPv4 address of the PCI is set to 0.0.0.0. The source ! port number is chosen by the PaC. The destination IPv4 address is ! set to 255.255.255.255. The destination port number is the PANA port ! number (716). [original] Step 1: The PaC initiates PANA by sending a broadcasted PCI carrying a Token AVP that contains a random value generated by the PaC. The source IPv4 address of the PCI is set to 0.0.0.0. The destination IPv4 address is set to 255.255.255.255. -----------------------------------------------</pre> Yasuyuki Tanaka 2012-02-09T05:44:37 http://permalink.gmane.org/gmane.ietf.pana/862 <pre>Hi Alper: El 21/12/2011, a las 10:18, Alper Yegin escribió: Yes, that's basically what I meant. 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-12-21T10:58:50 http://permalink.gmane.org/gmane.ietf.pana/861 <pre>Hi Rafa, On Dec 20, 2011, at 8:45 PM, Rafa Marin Lopez wrote: Good point. We can expand on that. We can informatively talk about how DHCP server/relay may be co-located with the PAA and how it responds to the PaC node only when the PANA authentication succeeds. This is one way of implementing/deploying the solution. There can be other ways as well. If that's what you were thinking, I can turn this into proposed text. Alper _______________________________________________ Pana mailing list Pana&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pana </pre> Alper Yegin 2011-12-21T09:18:03 http://permalink.gmane.org/gmane.ietf.pana/860 <pre>Hi all: I have been reading this document, and I believe the work is useful in some scenarios, so I support it. Also its content is clear to me and, therefore, I do not have really major concerns. However I was just wondering if some text could be included giving some comments about how to relate the obtention of the IP address after a successful authentication. I believe that there should be a relationship between them, since the PaC should not configure any IP address unless it is well authenticated (in the scenarios where this document applies). That link is missing in the document. Best regard. El 16/12/2011, a las 17:37, Alper Yegin escribió: ------------------------------------------------------- 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 ------------------------------------------------------- _____________________________________</pre> Rafa Marin Lopez 2011-12-20T18:45:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.pana