Subject: [Pana] Fwd: [IANA #454490] Last Call: <draft-ohba-pana-relay-03.txt> (Protocol for Carrying Authentication for Network Access (PANA) Relay Element) to Proposed Standard

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 09 Jun 2011 12:46:31 +0900

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: <draft-ohba-pana-relay-03.txt>
(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 <[email-masked]>
Reply-To: [email-masked]
CC: [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked]

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 document, there are two
IANA Actions that must be completed.

First, in the Message Types registry in the Protocol for Carrying
Authentication for Network Access (PANA) Parameters registry located at:

http://www.iana.org/assignments/pana-parameters/pana-parameters.xml

a single, new message type will be added as follows:

Value [ TBD ]
Name: PANA-Relay

IANA QUESTION --> How should the following field in the registry be
filled in?
Req/Ans: [ ??? ]

Abbrev: PRY
Reference: [ RFC-to-be ]

IANA notes that the authors request the value "5" for the Value of this
Message Type.

Second, in the AVP Codes registry in the the Protocol for Carrying
Authentication for Network Access (PANA) Parameters registry located at:

http://www.iana.org/assignments/pana-parameters/pana-parameters.xml

two new AVP Codes will be added as follows:

Code: [tbd2]
Attribute name: PaC-Information AVP
Reference: [ RFC-to-be ]

Code: [tbd3]
Attribute name: Relayed-Message AVP
Reference: [ RFC-to-be ]

IANA notes that the authors have requested codes "10" and "11" for
[tbd2] and [tbd3] respectively.

IANA understands that these two actions are the only ones required upon
approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This
message is only to confirm what actions will be performed.

Thanks,

Amanda Baber
IANA

On Wed May 25 13:37:06 2011, [email-masked] wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Protocol for Carrying Authentication for Network Access (PANA) Relay
>    Element'
>   <draft-ohba-pana-relay-03.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-06-22. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> 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) where the two nodes cannot reach each other by means of regular
> IP routing.
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ohba-pana-relay/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ohba-pana-relay/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 10 Jun 2011 10:58:09 +0300

I didn't understand why IANA assignment cares about the Req/Ans bit. Is it
really needed for IANA assignments?

If we need to use it, one option is to put "not applicable for PCI and PRY".

And if that's not acceptable/practical, then I'd say marking both PCI and
PRY with Req is OK. We could perceive them as requests that do not expect
answers. They are one-way messages. This is more logical to me than to
define an answer for which there is no outstanding request.

Alper

 

 

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On Behalf Of

> Sent: Thursday, June 09, 2011 6:47 AM

> To: [email-masked]

> Subject: [Pana] Fwd: [IANA #454490] Last Call: <draft-ohba-pana-relay-

> 03.txt> (Protocol for Carrying Authentication for Network Access (PANA)

> Relay Element) to Proposed Standard

> Authentication for Network Access (PANA) Parameters registry located

> at:

> Authentication for Network Access (PANA) Parameters registry located

> at:

> > The IESG has received a request from an individual submitter to

> consider

> > - 'Protocol for Carrying Authentication for Network Access (PANA)

> Relay

> > final comments on this action. Please send substantive comments to

> the

> > [email-masked] mailing lists by 2011-06-22. Exceptionally, comments

> may be

> _______________________________________________

> Pana mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/pana

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 11 Jun 2011 15:28:34 +0900

Alper,

(2011/06/10 16:58), Alper Yegin wrote:
> I didn't understand why IANA assignment cares about the Req/Ans bit. 
> Is it really needed for IANA assignments?

I agree, Req/Ans distinction may not be needed for IANA assignments.

> 
> If we need to use it, one option is to put “not applicable for PCI and 
> PRY”.
> 
> And if that’s not acceptable/practical, then I’d say marking both PCI 
> and PRY with Req is OK. We could perceive them as requests that do not 
> expect answers. They are one-way messages. This is more logical to me 
> than to define an answer for which there is no outstanding request.
> 

I agree to respond with IANA that Req/Ans distinction is not
applicable for PCI and PRY, with a back up plan of marking both PCI
and PRY as Req.

Thanks,
Yoshihiro Ohba

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jun 2011 11:09:47 -0400

On Fri, Jun 10, 2011 at 3:58 AM, Alper Yegin <[email-masked]> wrote:

>  ** **
> ** **

The Req/Ans column is needed to differentiate some of the messages, e.g.,
PAR and PAN, which have different abbreviations but share the same message
code.

> ****
> ** **

Reading RFC 5191 and the registry, I suggest that the Message Types registry
needs to be clarified a little, so that the column currently labeled Req/Ans
is tied directly to the 'R' Message Flag in the Message Flags registry.
 Giving the exact value for the 'R' flag in that column seems more direct.
 Perhaps rename "Req/Ans" to "R Message Flag", with values in the column of
'1', '0' or 'N/A' (the latter for PCI and PRE messages; although PCI is a
little tricky as its ABNF is defined without "REQ" and I don't know if that
ABNF implies the R Message Flag MUST be 0 or if it's a "don't care").

- Ralph

****
>
> ** **
>
> And if that’s not acceptable/practical, then I’d say marking both PCI and
> define an answer for which there is no outstanding request.****
>
> ** **
>
> Alper****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 Jun 2011 00:20:10 +0900

I agree with Ralph's suggestion to rename "Req/Ans" to "R Message
Flag".   In that case, the value in the column shall be either '1' or
'0' (and no 'N/A').

Regards,
Yoshihiro Ohba

(2011/06/24 0:09), Ralph Droms wrote:
> 
> 
> On Fri, Jun 10, 2011 at 3:58 AM, Alper Yegin <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     __ __
> 
>     __ __
> 
>     I didn't understand why IANA assignment cares about the Req/Ans
>     bit. Is it really needed for IANA assignments?
> 
> 
> The Req/Ans column is needed to differentiate some of the messages, 
> e.g., PAR and PAN, which have different abbreviations but share the 
> same message code.
> 
>     ____
> 
>     __ __
> 
>     If we need to use it, one option is to put “not applicable for PCI
>     and PRY”.
> 
> 
> Reading RFC 5191 and the registry, I suggest that the Message Types 
> registry needs to be clarified a little, so that the column currently 
> labeled Req/Ans is tied directly to the 'R' Message Flag in the 
> Message Flags registry.  Giving the exact value for the 'R' flag in 
> that column seems more direct.  Perhaps rename "Req/Ans" to "R Message 
> Flag", with values in the column of '1', '0' or 'N/A' (the latter for 
> PCI and PRE messages; although PCI is a little tricky as its ABNF is 
> defined without "REQ" and I don't know if that ABNF implies the R 
> Message Flag MUST be 0 or if it's a "don't care").
> 
> - Ralph
> 
> 
> 
>     ____
> 
>     __ __
> 
>     And if that’s not acceptable/practical, then I’d say marking both
>     PCI and PRY with Req is OK. We could perceive them as requests
>     that do not expect answers. They are one-way messages. This is
>     more logical to me than to define an answer for which there is no
>     outstanding request.____
> 
>     __ __
> 
>     Alper____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
> 
>      > Yoshihiro Ohba
> 
>      > To: [email-masked] <mailto:[email-masked]>
> 
>      > From: Amanda Baber via RT <[email-masked]
>     <mailto:[email-masked]>>
> 
>     <mailto:[email-masked]>
> 
>      > CC: [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>,
> 
>      > [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>,
> 
>      > [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>
> 
>      >
> 
>      > IESG:
> 
>      >
> 
>      > On Wed May 25 13:37:06 2011, [email-masked]
>     <mailto:[email-masked]> wrote:
> 
>      > >
> 
>      > > [email-masked] <mailto:[email-masked]> mailing lists by
>     2011-06-22. Exceptionally, comments
> 
>      > may be
> 
>      > > sent to [email-masked] <mailto:[email-masked]> instead. In
>     either case, please retain the
> 
>      > [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Jun 2011 20:40:45 +0300

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 Jun 2011 07:44:17 +0900

+1.

Yoshihiro Ohba

(2011/06/24 3:11), Robert Cragie wrote:
> I have no objection to either the text below or what was agreed with 
> Stephen earlier. On balance, I think the text below is preferable.
> 
> Robert
> 
> On 23/06/2011 6:47 PM, Samita Chakrabarti wrote:
>> As a co-author of the document, I am fine with the suggested text 
>> below.
>>
>> -Samita
>>
>> From: Jari Arkko [mailto:[email-masked]]
>> Sent: Thursday, June 23, 2011 10:41 AM
>> To: Yoshihiro Ohba; [email-masked]
>> Cc: Stephen Farrell; [email-masked]
>> Subject: IESG discussions on draft-ohba-pana-relay
>>
>> 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:
>>
>> used in untrusted networks, but if cryptographic mechanism is 
>> supported, it SHOULD be IPsec."
>>
>> Jari
>>
>>
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 24 Jun 2011 09:12:10 +0900

This table looks good to me.

Thanks,
Yoshihiro Ohba

(2011/06/24 3:13), Robert Cragie wrote:
> Too hasty with the cut and paste (too many PTR/PTA). Revised table:
> 
> Value        | R flag | Abbrev | Name                      | Reference |
> ------------------------------------------------------------------------
>   0           |        |        | Reserved                  | [RFC5191] |
>   1           | 0      | PCI    | PANA-Client-Initiation    | [RFC5191] |
>   2           | 1      | PAR    | PANA-Auth-Request         | [RFC5191] |
>   2           | 0      | PAN    | PANA-Auth-Answer          | [RFC5191] |
>   3           | 1      | PTR    | PANA-Termination-Request  | [RFC5191] |
>   3           | 0      | PTA    | PANA-Termination-Answer   | [RFC5191] |
>   4           | 1      | PNR    | PANA-Notification-Request | [RFC5191] |
>   4           | 0      | PNA    | PANA-Notification-Answer  | [RFC5191] |
>   5           | 0      | PRY    | PANA-Relay                | [RFCxxxx] |
>   6-65519     |        |        | Unassigned                | [RFC5191] |
>   65520-65535 |        |        | Reserved (Experimental)   | [RFC5191] |
> 
> On 23/06/2011 6:59 PM, Robert Cragie wrote:
>> As a follow up: as I read it in RFC 5191, the ABNF for PCI 
>> explicitly sets the R flag to 0. In some respects, given the 
>> definition of the R flag, this implies PCI is an answer, which is 
>> not really true. I don't know how important that is; it is used 
>> primarily for subclassifying a Message Type.
>>
>> On that basis, I think the table needs to look something like:
>>
>> Value        | R flag | Abbrev | Name                      | Reference |
>> ------------------------------------------------------------------------
>>  0           |        |        | Reserved                  | [RFC5191] |
>>  1           | 0      | PCI    | PANA-Client-Initiation    | [RFC5191] |
>>  2           | 1      | PAR    | PANA-Auth-Request         | [RFC5191] |
>>  2           | 0      | PAN    | PANA-Auth-Answer          | [RFC5191] |
>>  3           | 1      | PTR    | PANA-Termination-Request  | [RFC5191] |
>>  3           | 0      | PTA    | PANA-Termination-Answer   | [RFC5191] |
>>  4           | 1      | PTR    | PANA-Notification-Request | [RFC5191] |
>>  4           | 0      | PTA    | PANA-Notification-Answer  | [RFC5191] |
>>  5           | 0      | PRY    | PANA-Relay                | [RFCxxxx] |
>>  6-65519     |        |        | Unassigned                | [RFC5191] |
>>  65520-65535 |        |        | Reserved (Experimental)   | [RFC5191] |
>>
>>
>> Robert
>>
>> On 23/06/2011 6:26 PM, Robert Cragie wrote:
>>> Ralph,
>>>
>>> I like your suggestion for the Message Types registry. I guess 
>>> there is an assumption if the field is not declared in the ABNF it 
>>> becomes the same as reserved and thus follows the "set to zero and 
>>> ignored on receipt" rule. Does this need to be explicitly stated 
>>> anywhere?
>>>
>>> Robert
>>>
>>

---

From: Glen Zorn <[email-masked]>
Date: Fri, 24 Jun 2011 08:39:11 +0700

> used in untrusted networks, but if cryptographic mechanism is supported,

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

...

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 24 Jun 2011 10:51:37 +0300

Let's go with this.

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Friday, June 24, 2011 3:12 AM
> To: [email-masked]
> Cc: Ralph Droms; Alper Yegin; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; draft-ohba-pana-
> [email-masked]; [email-masked]
> Subject: Re: [Pana] Fwd: [IANA #454490] Last Call: <draft-ohba-pana-
> relay-03.txt> (Protocol for Carrying Authentication for Network Access
> (PANA) Relay Element) to Proposed Standard
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 24 Jun 2011 11:09:21 +0300

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

> Sent: Thursday, June 23, 2011 8:41 PM

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 24 Jun 2011 12:28:48 +0300

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

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Friday, June 24, 2011 11:52 AM
> To: Alper Yegin
> Cc: 'Jari Arkko'; 'Yoshihiro Ohba'; [email-masked]; draft-ohba-pana-
> [email-masked]; 'Stephen Farrell'
> Subject: Re: [Pana] IESG discussions on draft-ohba-pana-relay
> 
> On Jun 24, 2011, at 10:09, Alper Yegin wrote:
> 
> 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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 23:01:03 +0200

I'm fine this version as well.

jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Jun 2011 23:11:11 +0200

Stephen, Glen,

> 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