Re: Reminder: Call for Proposals - HTTP Authentication

Hi Lionel,

Do you know of any use outside of a mobile context? If there's interest, we can certainly look at it, but if
it's relegated to just that market (whether or technical or social reasons), I don't think this would
necessarily be the right place to advance it to a standard (speaking just for me).

Cheers,

On 01/05/2012, at 3:02 AM, <lionel.morand@...>
<lionel.morand@...> wrote:

> Any feedback?
> 
> Lionel
> 
> -----Message d'origine-----
> De : MORAND Lionel RD-CORE-ISS 
> Envoyé : vendredi 27 avril 2012 11:54
> À : 'Mark Nottingham'; 'HTTP Working Group'
> Objet : RE: Reminder: Call for Proposals - HTTP Authentication
> 
> Hi,
> 
> RFC 3310 is informational but used in mobile networks. I think it is worth to consider the interest of
defining this mechanism as "standard" HTTP authentication scheme. What should be the process?
> 
> In the same line, I have a draft on adaption of RFC3310 for 2G AKA (see.
http://tools.ietf.org/id/draft-morand-http-digest-2g-aka-02.txt). I would propose to add it to
the list of new potential authentication schemes but only if RFC 3310 is part of the same list. Otherwise,
it could be only informal.

RE: Reminder: Call for Proposals - HTTP Authentication

Hi Mark,

Of course, to be applicable, the first requirement for SIM-based authentication schemes is to have a SIM
card (or software based implementation) and this implies that you have a mobile subscription. 
However, the authentication mechanism is not contrite to mobile networks and can be typically used over
any HTTP-based access, e.g. wifi, adsl, cable, etc., the mobile network being used only for AAA purposes,
as trusted 3rd-party.
Moreover, the terminal itself can be a mobile phone but also any IP-enabled device (e.g. PC, tablet, etc.)
providing a API to the SIM card. Moreover, the browser is seen as off-the-shelf application and not mobile specific.

For the reasons, I was considering that it would be a general interest to reference a standard document
instead of an Informational RFC. And this period of "clean-up" of the HTTP documentation seems to be
suitable for that.

Regards,

Lionel

-----Message d'origine-----
De : Mark Nottingham [mailto:mnot@...] 
Envoyé : mardi 1 mai 2012 02:57
À : MORAND Lionel RD-CORE-ISS
Cc : ietf-http-wg@...
Objet : Re: Reminder: Call for Proposals - HTTP Authentication

Hi Lionel,

Do you know of any use outside of a mobile context? If there's interest, we can certainly look at it, but if
it's relegated to just that market (whether or technical or social reasons), I don't think this would
necessarily be the right place to advance it to a standard (speaking just for me).

Re: Reminder: Call for Proposals - HTTP Authentication

We can certainly discuss it. 

Would you be willing to write up a small Internet-Draft (e.g., 1-2 pages) outlining the proposal and any
work you see as necessary (either in modifying the RFC as it progresses, or adding more infrastructure to
make it more broadly usable?

Cheers,

On 01/05/2012, at 10:13 PM, <lionel.morand@...>
<lionel.morand@...> wrote:

> Hi Mark,
> 
> Of course, to be applicable, the first requirement for SIM-based authentication schemes is to have a SIM
card (or software based implementation) and this implies that you have a mobile subscription. 
> However, the authentication mechanism is not contrite to mobile networks and can be typically used over
any HTTP-based access, e.g. wifi, adsl, cable, etc., the mobile network being used only for AAA purposes,
as trusted 3rd-party.
> Moreover, the terminal itself can be a mobile phone but also any IP-enabled device (e.g. PC, tablet, etc.)
providing a API to the SIM card. Moreover, the browser is seen as off-the-shelf application and not mobile specific.
> 
> For the reasons, I was considering that it would be a general interest to reference a standard document
instead of an Informational RFC. And this period of "clean-up" of the HTTP documentation seems to be
suitable for that.
> 
> Regards,
> 
> Lionel
> 
> -----Message d'origine-----

Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt

HTTP folk,

Please have a look at this document and send along comments, especially if you're an intermediary or
firewall person, or consume the existing X-Forwarded-For header.

<http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

Cheers,

Begin forwarded message:

> From: Alexey Melnikov <alexey.melnikov@...>
> Subject: [apps-discuss] WGLC: draft-ietf-appsawg-http-forwarded-02.txt
> Date: 2 May 2012 4:26:50 AM AEST
> To: "apps-discuss@..." <apps-discuss@...>
> 
> Dear WG participants,
> I would like to initiate WG Last Call on draft-ietf-appsawg-http-forwarded-02.txt ("Forwarded HTTP
Extension"). Please send your reviews, as well as expressions of support regarding document readiness
for IESG (or not) either to the mailing list, or directly to WG chairs (Murray Kucherawy
<msk@...> and myself). Comments like "I've read the document
and it is Ok to publish" or "I've read the document and it has the following issues" are useful and would be
gratefully accepted by chairs.
> 
> The WGLC will end on Friday, May 18th.
> 
> Thank you,
> Alexey as an APPSAWG co-chair.
> 
> _______________________________________________

Amazon.com - Your Cancellation (12-612-4143)

Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>
>
> Cheers,
>

Okay, I've been over it with a finer toothed comb this time.

Here are the textual nits and grammer. Design issues in separate reply 
in case we end up with discussions.

** section 4 example #2 syntax error:

   Forwarded: For=192.0.2.43,"for=[2001:db8:cafe::17]:47011"
should be
   Forwarded: For=192.0.2.43,for="[2001:db8:cafe::17]:47011"

( \" moved)

* section 5.* normative MAY references are inconsistent.

5.1 ", but it can, however, be"
5.2 ", but it MAY also be"
5.3 "MAY be used for example by"
5.4 "This may be"

It looks to me like the normative MAY are not necessary since all the 
texts are informational examples of use. The 5.1, 5.2, 5.3 sentence 
structure could be aligned a bit better for more clarity as well.

** section 5.2 paragraph 1 and paragraph 3 contradict each other:

pgh 1 says "information about the user agent that initiated the 
request".
  The implication clearly being that there is only meant to be one for= 
parameter on the entire line, since there can only be one initiating 
user agent per request.

pgh 3 says "the first
    for-parameter will disclose the user agent where the request first
    was made, followed by any subsequent proxy identifiers."

.. while simultaneously explicitly describing a list of multiple.

Both of these also clash with the concept of proxy or tool originated 
requests where there is no "user agent" relevance. "client" is the term 
to use here in all paragraphs.

** section 6.1 spelling

  "note that an IPv6 adress"  =>  "address"

** section 7.1 grammer implication

Given the earlier section 4 stated the header was OPTIONAL and proxies 
MAY add or MAY delete things. The statement that "information might not 
be correctly updated" is a bit out of place.
  Dropping the word "correctly" out of that sentence brings it inline 
with the normative requirements.

AYJ

Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt - section 5.1

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>
>
> Cheers,
>

** section 5.1, must it be an interface label?

what about interception ports where the TCP details are not related to 
the interface in any way and both details needed?
what about interfaces labelled with non-alphanumeric characters?

AYJ

Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt - section 5.2

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>
>
> Cheers,
>

** section 5.2

Now that it is mentioning the X-Forwarded-* class of headers and 
describing security usage for Forwarded: the document needs a safe 
mapping from X-Forwarded-For to Forwarded:. I have spent quite a while 
attempting to iterate the cases and find a safe mapping method for Squid 
to use mapping the fields of XFF to records in Forwarded:, but there is 
always one case or other which fails badly.

IMO the mapping should be:
"
A recipient of X-Forwarded-For header MUST either, drop all 
X-Forwarded-For: and Forwarded: headers in the request, or drop the 
X-Forwarded-For header and place a single obfuscated identifier 
field-value in the Forwarded: header prior to any other information 
additions of its own. This must be done before interpreting either 
header.
"

For example:
  client 1.2.3.4:8765 sending
    Forwarded: for=[::1]
    X-Forwarded-For: ...

becomes:
   Forwarded: for=[::1], _abc, for="1.2.3.4:8765"

This retains the security properties of the XFF header environment 
because:
  1) Dropping is safe because both these are OPTIONAL headers.
  2) Using an obfuscated identifier and retaining the Forwarded: header 
preserves what information is likely safe but places a blocking step at 
the position of the un-trustable hop.

The other X-Forwarded-* headers need a similar security protection 
fixup in the sections they map into.

AYJ

Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt - section 6 ABNF

On 02.05.2012 11:33, Mark Nottingham wrote:
> HTTP folk,
>
> Please have a look at this document and send along comments,
> especially if you're an intermediary or firewall person, or consume
> the existing X-Forwarded-For header.
>
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>
>
> Cheers,
>

** section 6 ABNF clash between port and obfport is still a nasty 
thorn.

IMO obfport should start with a mandatory '_'. We have to special-case 
it anyway to parse the ALPHA component might as well bring it inline 
with the rules for obfuscated node and obfuscated identifier ABNF.

Alternatively why bother with obfport at all?

  As I understand/recall it the use-case was to enable for= or by= with 
a visible IP and obfscated/private port.

Would not allowing one of the listed field values be obfuscated 
identifier be better? that way the port can be omitted entirely from the 
for= and whatever detail the hop needs to obfuscate and pass on can be 
encoded inside the obfuscated identifier token.

AYJ

Re: Fwd: WGLC: draft-ietf-appsawg-http-forwarded-02.txt

Hi Mark,

On Wed, May 02, 2012 at 09:33:53AM +1000, Mark Nottingham wrote:
> HTTP folk,
> 
> Please have a look at this document and send along comments, especially if you're an intermediary or
firewall person, or consume the existing X-Forwarded-For header.
> 
> <http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-02>

A quick note before it escapes my mind, for 8.2. Information leak :

I would add :
   This header field must never be copied into response messages by origin
   servers or intermediaries for whatever reason as it can reveal the whole
   proxy chain to the client. As a side effect, Special care must be taken
   in hosting environments not to allow the TRACE request where the Forwarded
   field is used, as it would appear in the body of the response message.

I'll probably have other comments and agree with those raised by Amos.

Regards,
Willy