Subject: Re: [secdir] Review of draft-ietf-oauth-assertions-09

From: Shawn Emery <[email-masked]>
Date: Wed, 06 Feb 2013 01:37:32 -0700

A new version of this draft has been made, 10, which implicitly 
addresses the concerns that I had brought up during the secdir review.

Shawn.
--
On 12/30/12 12:07 AM, Shawn Emery wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This internet-draft describes an assertion framework for the OAuth 2.0 protocol.  Given that
> that this is a framework, subsequent drafts would be needed for a deployed mechanism.
>
> The security considerations section does exist and outlines various issues including
> impersonation, replay, and privacy.  The section then suggests ways of mitigating these
> threats.  This seems sufficient, but can there be more guidance on the Assertion ID to
> avoid collision or replay (e.g. length, roll-over, etc.)?
>
> General comments:
>
> None.
>
> Editorial comments:
>
> Redundant wordings, suggested fix:
>
> Old:
>
>   An IEFT URN for use as the "XXXX" value can be requested using
>   the template in An IETF URN Sub-Namespace for OAuth [RFC6755  <http://tools.ietf.org/html/rfc6755>].
>
> New:
>
>   An IEFT URN for use as the "XXXX" value can be requested using
>   the template in [RFC6755  <http://tools.ietf.org/html/rfc6755>].
>
> Shouldn't urn:ietf:params:oauth:grant_type:* be
> urn:ietf:params:oauth:grant-type:*?
>
> s/included yet all/included, yet all/
>
> Shawn.
> --
>
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Shawn Emery <[email-masked]>
Date: Wed, 20 Feb 2013 00:59:54 -0700

This internet-draft describes a way to provide a client link-layer 
addresses in DHCPv6 Relay-Forward messages..

The security considerations section does exist and discusses an attack 
scenario involving rogue relay agents and clients where a DHCPv6 node 
could spoof the address of a separate DHCPv4 node.  Subsequently if a 
Dynamic DNS update is made then a dual-stack node could be made to 
connect to the DHCPv6 client instead of the DHCPv4 client.  To thwart 
such an attack the draft recommends that administrators configure IPsec 
between the DHCP server(s) and the relay agents.  Besides the security 
considerations of DHCP in general, I think that this document adequately 
covers the feature being introduced.

General comments:

None.

Editorial comments:

s/will help above mentioned scenarios/will help with the scenarios 
mentioned above/
s/used in wide/used in a wide/

Shawn.
--

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 20 Feb 2013 08:37:04 +0000

Thanks Shawn for review.

We will take care of your Editorial comments in the next revision or at the time of AUTH48 (whichever is earlier.)

Regards
-Gaurav
-----Original Message-----
From: Shawn Emery [mailto:[email-masked]] 
Sent: Wednesday, February 20, 2013 1:30 PM
To: [email-masked]
Cc: [email-masked]; The IESG
Subject: Review of draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This internet-draft describes a way to provide a client link-layer addresses in DHCPv6 Relay-Forward messages..

The security considerations section does exist and discusses an attack scenario involving rogue relay agents and clients where a DHCPv6 node could spoof the address of a separate DHCPv4 node.  Subsequently if a Dynamic DNS update is made then a dual-stack node could be made to connect to the DHCPv6 client instead of the DHCPv4 client.  To thwart such an attack the draft recommends that administrators configure IPsec between the DHCP server(s) and the relay agents.  Besides the security considerations of DHCP in general, I think that this document adequately covers the feature being introduced.

General comments:

None.

Editorial comments:

s/will help above mentioned scenarios/will help with the scenarios mentioned above/ s/used in wide/used in a wide/

Shawn.
--