headers
Yoshihiro Ohba | 21 Jan 2013 02:27
Picon

"PRF key" in RFC 5191 Section 8.5

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
Permalink | Reply | 1 comment |
headers
Rafa Marin Lopez | 8 May 2012 16:06
Picon
Favicon

OpenPANA and PANA Relay Implementation

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 


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 <at> 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 <at> um.es
-------------------------------------------------------




_______________________________________________
Pana mailing list
Pana <at> ietf.org
https://www.ietf.org/mailman/listinfo/pana
Permalink | Reply | 0 comments |
headers
Robert Cragie | 10 Apr 2012 12:48

Fwd: New Version Notification for draft-yegin-pana-encr-avp-02.txt

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: Date: From: To: CC:
New Version Notification for draft-yegin-pana-encr-avp-02.txt
Tue, 10 Apr 2012 03:45:04 -0700
internet-drafts <at> ietf.org
robert.cragie <at> gridmerge.com
alper.yegin <at> 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
Attachment (smime.p7s): application/pkcs7-signature, 5160 bytes
_______________________________________________
Pana mailing list
Pana <at> ietf.org
https://www.ietf.org/mailman/listinfo/pana
Permalink | Reply | 0 comments |
headers
Robert Cragie | 16 Mar 2012 12:04

Fwd: New Version Notification for draft-yegin-pana-encr-avp-01.txt

I would like to move this forward so I am soliciting any comments from the PANA mailing list.

Thanks

Robert

-------- Original Message -------- Subject: Date: From: To: CC:
New Version Notification for draft-yegin-pana-encr-avp-01.txt
Wed, 04 Jan 2012 01:53:07 -0800
internet-drafts <at> ietf.org
alper.yegin <at> yegin.org
robert.cragie <at> gridmerge.com, alper.yegin <at> 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
Attachment (smime.p7s): application/pkcs7-signature, 5160 bytes
_______________________________________________
Pana mailing list
Pana <at> ietf.org
https://www.ietf.org/mailman/listinfo/pana
Permalink | Reply | 2 comments |
headers
Yoshihiro Ohba | 13 Feb 2012 10:01
Picon

Fwd: Re: I-D Action: draft-yegin-pana-unspecified-addr-05.txt

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 <yoshihiro.ohba <at> toshiba.co.jp>
To: Alper Yegin <alper.yegin <at> yegin.org>

(2012/02/09 18:11), Alper Yegin wrote:

(snip)

>> ---------------------------------------------------------------------
>>
>> (3) Page 6, Paragraph 3
>>
>> I have no idea which PAR should have 'I' bit. Every PAR sent by
>> PAA should have 'I' bit? Or, only a PAR with 'C' bit should have
>> 'I' bit? (I think the latter is preferable.)
>>
>> I've referred to RFC 5191, but I've not found the answer.
>>
> 
> I think this is an ambiguity with the RFC 5191. PAR with 'C' bit makes sense.
> 

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

> 
>> [original]
>>   The PAA SHALL set the 'I' (IP Reconfiguration) bit of PAR messages
>>   in authentication and authorization phase so that the PaC proceeds
>>   to IP address configuration.
>>
>> ---------------------------------------------------------------------
>>
>> (4) Page 6, Paragraph 7
>> I don't think that the description about the size of the largest PANA
>> is correct. This is because the initial PAR could have multiple
>> Integrity-Algorithm AVPs and PRF-Algorithm AVPs. This specification is
>> described in Section 4.1, RFC 5191.
>>
>> [Section 4.1. in RFC 5191]
>>    the PAA sends the initial PANA-Auth-Request carrying one or more
>>    PRF-Algorithm AVPs and one or more Integrity-Algorithm AVPs for the
>>    PRF and integrity algorithms supported by it, respectively.
>>
>> In my understanding, it is sufficient to consider a PANA Message which
>> has only one EAP-Payload AVP for "Message Size Considerations". In
>> other words, the minimum PANA MTU size is equivalent to the size of a
>> PANA message which has only one EAP-Payload AVP.
>>
> 
> 
> 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
> 
> 
> 
>> ---------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Pana mailing list
>> Pana <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/pana
> 
> _______________________________________________
> Pana mailing list
> Pana <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pana
>
Permalink | Reply | 2 comments |
headers
RFC Errata System | 14 Oct 2011 08:52
Favicon

[Technical Errata Reported] RFC5191 (2997)


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&eid=2997

--------------------------------------
Type: Technical
Reported by: Yoshihiro Ohba <yoshihiro.ohba <at> toshiba.co.jp>

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 report, if necessary. 

--------------------------------------
RFC5191 (draft-ietf-pana-pana-18)
--------------------------------------
Title               : Protocol for Carrying Authentication for Network Access (PANA)
Publication Date    : May 2008
Author(s)           : D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin
Category            : PROPOSED STANDARD
Source              : Protocol for carrying Authentication for Network Access
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
Permalink | Reply | 0 comments |
headers
Yoshihiro Ohba | 13 Oct 2011 15:50
Picon

RFC 6345 errata

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/ in the last sentence.)

Regards,
Yoshihiro Ohba
Permalink | Reply | 4 comments |
headers
Rafa Marin Lopez | 29 Sep 2011 13:41
Picon
Favicon

Open source PANA implementation (OpenPANA)

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 <at> 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 <at> um.es
-------------------------------------------------------




_______________________________________________
Pana mailing list
Pana <at> ietf.org
https://www.ietf.org/mailman/listinfo/pana
Permalink | Reply | 2 comments |
headers
Jari Arkko | 30 Jun 2011 23:11

Re: IESG discussions on draft-ohba-pana-relay

Stephen, Glen,

>>> "PRE/PAA security is OPTIONAL since PANA messages are designed to be
>>> used in untrusted networks, but if cryptographic mechanism is supported,
>>> it SHOULD be IPsec."
>>>       
>> This is an interesting statement.  Just one question: if it is not
>> possible to use the protocol in a secure fashion (the claim being that
>> MITM attacks are impossible to prevent), how is it that the protocol is
>> "designed to be used in untrusted networks"?
>>     
>
> So the suggested text does assume that the pana messages are well
> protected between the PaC and PAA and that the PRE is security-wise
> just the same as any old router on the path.
>
> If pana messages are actually commonly sent that are vulnerable to
> some attacks on the messages themselves, then IPsec between the PRE
> and PAA would add enough value that I'd want it as a SHOULD.
>
> However, I'm told that this is not the case and so the text above
> should be fine.
>
> But if the reality differs, I'd like to know about that.
>   

Obviously, we do not necessarily know what the reality will be with PANA 
use, there is not much deployed practice to look at. I think most people 
would run a cryptographically well designed EAP methods.

My point was that even with such methods, a MITM can cause PANA to fail 
and network access to be prevented. This is true of many things, 
including IPsec. If I'm in a position to drop selected messages, for 
instance, I can prevent an IPsec tunnel from being established. Still, 
we like to think that IPsec has been designed to be used in untrusted 
environments. It just cannot deal with all types of attacks, just with 
some. Just like PANA.

I have sent an approved message for this draft with an RFC Editor note 
using Alper's suggested text. If there are further text tweaks please 
handle them in AUTH48. If there is further discussion of bigger issues, 
we can bring the document back for another look at the IESG.

Jari
Permalink | Reply | 0 comments |
headers
Jari Arkko | 30 Jun 2011 23:01

Re: IESG discussions on draft-ohba-pana-relay

I'm fine this version as well.

jari

Alper Yegin kirjoitti:
> I think importing text from the other one Stephen had suggested would be an
> improvement. Like this:
>
>
> 3. Security of Messages Sent between PRE and PAA
>
> PRE/PAA security is OPTIONAL since PANA messages are designed to be
> used in untrusted networks, but if cryptographic mechanism is
> supported, it SHOULD be IPsec. When the device characteristics preclude
> support for IPsec, an alternative mechanism such as DTLS [REF], or
> link-layer cryptographic security, etc. may be used instead. This section
> describes how IPsec [RFC4301] can be used for securing the PANA relay
> messages.
>
> Alper
>
>
>
>
>   
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko <at> piuha.net]
>> Sent: Thursday, June 23, 2011 8:41 PM
>> To: Yoshihiro Ohba; pana <at> ietf.org
>> Cc: Stephen Farrell; draft-ohba-pana-relay <at> tools.ietf.org
>> Subject: IESG discussions on draft-ohba-pana-relay
>>
>> We discussed this draft today. The remaining Discuss was about how
>> mandatory we should make IPsec. You had discussed about a SHOULD with
>> Stephen. I suggested that while interoperability is useful and
>> mandatory-to-implement mechanisms are good for it, we also have to talk
>> about how much value we bring with a security mechanism. In this case
>> there are some issues like MITMs able to block PANA packets. However,
>> some of these vulnerabilities are not helped by relay - PAA security,
>> as
>> the relay can still do bad things, and because ARP/ND vulnerabilities
>> between the client and relay in any case make it possible to become a
>> MITM. Stephen had some suggested text that I agree with:
>>
>> "PRE/PAA security is OPTIONAL since PANA messages are designed to be
>> used in untrusted networks, but if cryptographic mechanism is
>> supported,
>> it SHOULD be IPsec."
>>
>> Jari
>>     
>
>
>
Permalink | Reply | 0 comments |
headers
Alper Yegin | 24 Jun 2011 11:28

Re: IESG discussions on draft-ohba-pana-relay

Carsten,

Section 6. Security Considerations talks about the threats, some of which
are already handled by the base EAP/PANA design. Other threats that are
relevant to introduction of the PRE, they are described and the PRE-PAA
security is pointed accordingly.

Alper

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo <at> tzi.org]
> Sent: Friday, June 24, 2011 11:52 AM
> To: Alper Yegin
> Cc: 'Jari Arkko'; 'Yoshihiro Ohba'; pana <at> ietf.org; draft-ohba-pana-
> relay <at> tools.ietf.org; 'Stephen Farrell'
> Subject: Re: [Pana] IESG discussions on draft-ohba-pana-relay
> 
> On Jun 24, 2011, at 10:09, Alper Yegin wrote:
> 
> > PRE/PAA security is OPTIONAL since PANA messages are designed to be
> > used in untrusted networks, but if cryptographic mechanism is
> > supported, it SHOULD be IPsec. When the device characteristics
> preclude
> > support for IPsec, an alternative mechanism such as DTLS [REF], or
> > link-layer cryptographic security, etc. may be used instead. This
> section
> > describes how IPsec [RFC4301] can be used for securing the PANA relay
> > messages.
> 
> It would be useful to be very explicit what the objectives for this
> "PRE/PAA security" might be.
> Section 6 seems to suggest there is no real need for this at all (but
> then nebulously talks about "residual risks").
> So, unless we say what this is good for, it is hard to assess whether
> the "PRE/PAA security" is actually meeting those objectives.
> (E.g., if the purpose is DoS mitigation, a security scheme that is as
> susceptible to DoS attacks as the PAA itself, isn't that useful.)
> 
> Gruesse, Carsten
Permalink | Reply | 0 comments |

Gmane