search

httpwg / httpbis-issues

1 stars 1 forks source link

IESG ballot on draft-ietf-httpbis-authscheme-registrations-09 #530

Closed mnot closed 3 years ago

mnot commented 10 years ago

Benoit Claise

Comment (2013-12-18)

No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer: I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should reviewed together:

I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations. I have read all three drafts.

So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready: It is just really unclear exactly what IANA is putting in http://www.iana.org/assignments/http-authschemes

Here’s my guess: I think that IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

              [Digest] |[Negotiate]| [OAuth]

What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it. Without looking at the whole scheme, you cannot tell if this is reason.

I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.

1) Basic: RFC 2617: section 2 (nothing)

2) Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used. The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC, why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes? Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak. What exactly the author is trying to suggest needs to be included in the registry is not clear.

4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system. The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5) OAuth: RFC5849: Section 3.5.1

Authorization: OAuth realm="Example",

    oauth_consumer_key="0685bd9184jfhq22",

    oauth_token="ad180jjd733klru7",

    oauth_signature_method="HMAC-SHA1",

    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

    oauth_timestamp="137131200",

    oauth_nonce="4572616e48616d6d65724c61686176",

    oauth_version="1.0"

I have confirmed that referenced documents in do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.

What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

''answered in http://www.ietf.org/mail-archive/web/ops-dir/current/msg00065.html''

Sean Turner

Comment (2013-12-18)

I might have said the following in addition to no security considerations:

Security considerations for each method are described in the referenced RFC.

'' see 2515 ''

Stephen Farrell

Comment (2013-12-19)

nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.

'' see 2515 ''

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/530

mnot commented 10 years ago

Benoit Claise

Comment (2013-12-18)

No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer: I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should reviewed together:

  • draft-ietf-httpbis-p1-messaging

  • draft-ietf-httpbis-p2-semantics

  • draft-ietf-httpbis-p4-conditional

  • draft-ietf-httpbis-p5-range

  • draft-ietf-httpbis-p6-cache

  • draft-ietf-httpbis-p7-auth (Peter Schoenmaker Ops-Dir reviewer)

  • draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir

  • draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)

I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations. I have read all three drafts.

So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready: It is just really unclear exactly what IANA is putting in http://www.iana.org/assignments/http-authschemes

Here’s my guess: I think that IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

              [Digest] |[Negotiate]| [OAuth]

What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it. Without looking at the whole scheme, you cannot tell if this is reason.

I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.

1) Basic: RFC 2617: section 2 (nothing)

2) Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used. The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC, why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes? Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak. What exactly the author is trying to suggest needs to be included in the registry is not clear.

4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system. The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5) OAuth: RFC5849: Section 3.5.1

Authorization: OAuth realm="Example",

    oauth_consumer_key="0685bd9184jfhq22",

    oauth_token="ad180jjd733klru7",

    oauth_signature_method="HMAC-SHA1",

    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

    oauth_timestamp="137131200",

    oauth_nonce="4572616e48616d6d65724c61686176",

    oauth_version="1.0"

I have confirmed that referenced documents in do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.

What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

Sean Turner

Comment (2013-12-18)

I might have said the following in addition to no security considerations:

Security considerations for each method are described in the referenced RFC.

Stephen Farrell

Comment (2013-12-19)

nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.

to:

Benoit Claise

Comment (2013-12-18)

No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer: I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should reviewed together:

  • draft-ietf-httpbis-p1-messaging

  • draft-ietf-httpbis-p2-semantics

  • draft-ietf-httpbis-p4-conditional

  • draft-ietf-httpbis-p5-range

  • draft-ietf-httpbis-p6-cache

  • draft-ietf-httpbis-p7-auth (Peter Schoenmaker Ops-Dir reviewer)

  • draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir

  • draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)

I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations. I have read all three drafts.

So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready: It is just really unclear exactly what IANA is putting in http://www.iana.org/assignments/http-authschemes

Here’s my guess: I think that IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

              [Digest] |[Negotiate]| [OAuth]

What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it. Without looking at the whole scheme, you cannot tell if this is reason.

I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.

1) Basic: RFC 2617: section 2 (nothing)

2) Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used. The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC, why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes? Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak. What exactly the author is trying to suggest needs to be included in the registry is not clear.

4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system. The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5) OAuth: RFC5849: Section 3.5.1

Authorization: OAuth realm="Example",

    oauth_consumer_key="0685bd9184jfhq22",

    oauth_token="ad180jjd733klru7",

    oauth_signature_method="HMAC-SHA1",

    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

    oauth_timestamp="137131200",

    oauth_nonce="4572616e48616d6d65724c61686176",

    oauth_version="1.0"

I have confirmed that referenced documents in do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.

What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

''answered in http://www.ietf.org/mail-archive/web/ops-dir/current/msg00065.html''

Sean Turner

Comment (2013-12-18)

I might have said the following in addition to no security considerations:

Security considerations for each method are described in the referenced RFC.

Stephen Farrell

Comment (2013-12-19)

nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2515:

remove misleading statement about standards-track; hint about scheme related security considerations (see #530)

mnot commented 10 years ago

Benoit Claise

Comment (2013-12-18)

No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer: I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should reviewed together:

  • draft-ietf-httpbis-p1-messaging

  • draft-ietf-httpbis-p2-semantics

  • draft-ietf-httpbis-p4-conditional

  • draft-ietf-httpbis-p5-range

  • draft-ietf-httpbis-p6-cache

  • draft-ietf-httpbis-p7-auth (Peter Schoenmaker Ops-Dir reviewer)

  • draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir

  • draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)

I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations. I have read all three drafts.

So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready: It is just really unclear exactly what IANA is putting in http://www.iana.org/assignments/http-authschemes

Here’s my guess: I think that IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

              [Digest] |[Negotiate]| [OAuth]

What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it. Without looking at the whole scheme, you cannot tell if this is reason.

I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.

1) Basic: RFC 2617: section 2 (nothing)

2) Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used. The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC, why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes? Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak. What exactly the author is trying to suggest needs to be included in the registry is not clear.

4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system. The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5) OAuth: RFC5849: Section 3.5.1

Authorization: OAuth realm="Example",

    oauth_consumer_key="0685bd9184jfhq22",

    oauth_token="ad180jjd733klru7",

    oauth_signature_method="HMAC-SHA1",

    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

    oauth_timestamp="137131200",

    oauth_nonce="4572616e48616d6d65724c61686176",

    oauth_version="1.0"

I have confirmed that referenced documents in do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.

What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

''answered in http://www.ietf.org/mail-archive/web/ops-dir/current/msg00065.html''

Sean Turner

Comment (2013-12-18)

I might have said the following in addition to no security considerations:

Security considerations for each method are described in the referenced RFC.

Stephen Farrell

Comment (2013-12-19)

nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.

to:

Benoit Claise

Comment (2013-12-18)

No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer: I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should reviewed together:

  • draft-ietf-httpbis-p1-messaging

  • draft-ietf-httpbis-p2-semantics

  • draft-ietf-httpbis-p4-conditional

  • draft-ietf-httpbis-p5-range

  • draft-ietf-httpbis-p6-cache

  • draft-ietf-httpbis-p7-auth (Peter Schoenmaker Ops-Dir reviewer)

  • draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir

  • draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)

I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations. I have read all three drafts.

So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready: It is just really unclear exactly what IANA is putting in http://www.iana.org/assignments/http-authschemes

Here’s my guess: I think that IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

              [Digest] |[Negotiate]| [OAuth]

What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it. Without looking at the whole scheme, you cannot tell if this is reason.

I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.

1) Basic: RFC 2617: section 2 (nothing)

2) Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used. The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC, why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes? Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3) Digest: RFC 2617: Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak. What exactly the author is trying to suggest needs to be included in the registry is not clear.

4) Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system. The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5) OAuth: RFC5849: Section 3.5.1

Authorization: OAuth realm="Example",

    oauth_consumer_key="0685bd9184jfhq22",

    oauth_token="ad180jjd733klru7",

    oauth_signature_method="HMAC-SHA1",

    oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

    oauth_timestamp="137131200",

    oauth_nonce="4572616e48616d6d65724c61686176",

    oauth_version="1.0"

I have confirmed that referenced documents in do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.

What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

''answered in http://www.ietf.org/mail-archive/web/ops-dir/current/msg00065.html''

Sean Turner

Comment (2013-12-18)

I might have said the following in addition to no security considerations:

Security considerations for each method are described in the referenced RFC.

'' see 2515 ''

Stephen Farrell

Comment (2013-12-19)

nitty nit nit: suggest s/defined in standards-track RFCs/defined in RFCs/ might be better - reading this I got a scare for a second that that registry might require standards-track but it doesn't, its IETF review.

'' see 2515 ''