Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-nslp-auth-02.txt

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 2 Jun 2010 11:35:51 +0200

Hi Jukka

I have checked this version of the draft and I think that it can go for
WGLC!

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jukka Manner
> Sent: maandag 24 mei 2010 10:47
> To: [email-masked]
> Subject: Re: [NSIS] I-D Action:draft-ietf-nsis-nslp-auth-02.txt
> 
> Dear all,
> 
> This is our final document to be going to the IESG sometime soon.
> 
> Please submit comments within the next week or so, and let's 
> discuss this topic a bit before I issue an official WGLC.
> 
> All comments for or against the work, and proposals to update 
> the draft are most welcome.
> 
> regards,
> Jukka
> 
> On 05/16/2010 01:45 AM, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> > This draft is a work item of the Next Steps in Signaling 
> Working Group of the IETF.
> >
> >
> > 	Title           : Authorization for NSIS Signaling 
> Layer Protocols
> > 	Author(s)       : J. Manner, et al.
> > 	Filename        : draft-ietf-nsis-nslp-auth-02.txt
> > 	Pages           : 40
> > 	Date            : 2010-05-15
> >
> > Signaling layer protocols specified within the NSIS 
> framework may rely 
> > on the GIST (General Internet Signaling Transport) protocol 
> to handle 
> > authorization.  Still, the signaling layer protocol above 
> GIST itself 
> > may require separate authorization to be performed when a node 
> > receives a request for a certain kind of service or 
> resources.  This 
> > draft presents a generic model and object formats for session 
> > authorization within the NSIS Signaling Layer Protocols.  
> The goal of 
> > session authorization is to allow the exchange of 
> information between 
> > network elements in order to authorize the use of resources for a 
> > service and to coordinate actions between the signaling and 
> transport 
> > planes.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-auth-02.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nsis
> 
> --
> Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+470 22481
> Aalto University                  Mobile: +358+(0)50+5112973
> Department of Communications      Fax:    +358+(0)9+470 22474
> and Networking (Comnet)           Office: G320a (Otakaari 5A)
> P.O. Box 13000, FIN-00076 Aalto   E-mail: [email-masked]
> Finland                           www.netlab.hut.fi/~jmanner/
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nsis
>

---

From: Jukka Manner <[email-masked]>
Date: Mon, 07 Jun 2010 11:09:36 +0300

Dear all,

This message starts a two week Working Group Last Call on the 
authorization document. Please review the document send you comments, 
even a simple "yes, looks good to me" is valuable information.

The WGLC ends on Monday 21st of June 2010.

Regards,
Jukka

On 16.5.2010 1:45, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Next Steps in Signaling Working Group of the IETF.
>
>
> 	Title           : Authorization for NSIS Signaling Layer Protocols
> Signaling layer protocols specified within the NSIS framework may
> rely on the GIST (General Internet Signaling Transport) protocol to
> handle authorization.  Still, the signaling layer protocol above GIST
> itself may require separate authorization to be performed when a node
> receives a request for a certain kind of service or resources.  This
> authorization within the NSIS Signaling Layer Protocols.  The goal of
> session authorization is to allow the exchange of information between
> service and to coordinate actions between the signaling and transport
> planes.
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 11 Jun 2010 16:15:08 +0300

Summary: Not ready, revision needed, see below.

Meta question: This document is very complex. Do we have any real experience with coupling NSLP authorization with X.500, Kerberos, PGP, etc.? Do any of the experimental implementations use this to authorize QoS NSLP or NATFW NSLP actions?

Section 1., paragraph 2:
>    Currently, this node would run either the QoS or
>    the NAT/FW NSLP service.

  Cite the two NSLP documents.

Section 2., paragraph 1:
>    The NSIS working group is specifying a suite of protocols for the
>    next generation in Internet signaling [RFC4080].

  Rephrase to omit mentioning the NSIS WG before publication as an RFC.

Section 2., paragraph 3:
>    The so far specified basic security architecture for NSIS is based on

  s/so far specified//   (there won't be any other, no?)

Section 3.1., paragraph 8:
>    flag cominbation is not used by all NSLPs, e.g., it is not used in

  Nit: s/cominbation/combination/

Section 3.2., paragraph 5:
>       Session authorization attribute type (X-Type) field is one octet.
>       IANA acts as a registry for X-Types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following X-Types:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.

Section 3.2.1., paragraph 6:
>       The following sub-types for AUTH_ENT_ID are defined.  IANA acts as
>       a registry for AUTH_ENT_ID sub-types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following sub-types of AUTH_ENT_ID:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.

Section 3.2.2., paragraph 6:
>       The following sub types for SOURCE_ADDR are defined.  IANA acts as
>       a registry for SOURCE_ADDR sub-types as described in Section 7,
>       IANA Considerations.  Initially, the registry contains the
>       following sub types for SOURCE_ADDR:

  The IANA considerations are in Section 8. And that section doesn't
  define this new registry.

Section 3.2.3., paragraph 3:
>    Length: Length of the attribute in number of octects, which MUST be >

  Nit: s/octects,/octets,/

Section 1., paragraph 0:
>    1.  1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.

  RFC1305 needs to be a normative reference.

Section 3.2.6., paragraph 2:
>    The creator of the this attribute lists every NSLP object type whose

  Nit: Maybe you need to remove the second determiner so that only 'the'
  or 'this' is left.

Section 3.2.6., paragraph 6:
>    | No of signed NSLP objects = n |  rsv  |  NSLP object type (1) |

  Nit: s/No/Nr./ (also elsewhere)

Section 3.2.6., paragraph 10:
>    SubType: No sub types for NSLP_OBJECT_LIST are currently defined.
>    This field MUST be set to 0.

  And ignored upon reception.

Section 3.2.6., paragraph 13:
>    rsv: reserved bits and must be set to 0 (zero).

  And ignored upon reception.

Section 3.2.6., paragraph 15:
>    padding: padding is required if the number of NSLP objects is even.
>    The padding field MUST be 16 bit set to 0.

  Ambiguous. You mean that the padding is REQUIRED when even and that it
  MUST NOT be added when odd.

Section 4.2., paragraph 3:
>    Another opton is to encapsulate the credentials in the AUTH_DATA

  Nit: s/opton/option/

Section 4.3.1.1., paragraph 5:
>    o  Certification Path Validation is performed as defined in Section 6
>       of RFC 3280.

  RFC3280 needs to be cited.

Section 4.3.1.2., paragraph 2:
>    o  AUTHENTICATION_DATA contains a Signature Packet as defined in
>       Section 5.2.3 of RFC 2440.  In summary:

  RFC2440 needs to be cited.

Section 6.2., paragraph 0:
> 6.2.  Processing within the QoS NSLP

  Does this mean that this document updates draft-ietf-nsis-qos-nslp?

Section 2., paragraph 0:
>        must contruct and send a RESPONSE message with the status of

  Nit: s/contruct/construct/

Section 6.3., paragraph 0:
> 6.3.  Processing with the NAT/FW NSLP

  Does this mean that this document updates draft-ietf-nsis-nslp-natfw?

Section 7., paragraph 2:
>    different network entities may not be in synch.  The start time is

  Nit: s/synch./sync./

Section 10.2., paragraph 4:
>    [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>               Resource Identifiers (URI): Generic Syntax", RFC 2396,
>               August 1998.

  Obsolete informational reference (is this intentional?): RFC 2396
  (Obsoleted by RFC 3986)

Section 10.2., paragraph 7:
>    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
>               RFC 3852, July 2004.

  Obsolete informational reference (is this intentional?): RFC 3852
  (Obsoleted by RFC 5652)

---

From: Roland Bless <[email-masked]>
Date: Fri, 11 Jun 2010 16:09:02 +0200

Hi Lars,

on 11.06.2010 15:15, Lars Eggert wrote:
> Meta question: This document is very complex. Do we have any real

I guess that this problem is caused by the fact that
the document heavily bases on the
Session Authorization Policy Element for RSVP (RFC 3520).

> experience with coupling NSLP authorization with X.500, Kerberos,
> PGP, etc.? Do any of the experimental implementations use this to

So the question is: is RFC 3520 really used anywhere in existing
RSVP deployments? If not, probably we can dismiss most of the
RFC 3520 legacy stuff and aim for something simpler (that
is actually my preference), since there is no reason for code
reuse.

> authorize QoS NSLP or NATFW NSLP actions?

We actually implemented the HMAC_SIGNED part and the full
PDU structure including all objects. Currently, however,
we have no interworking with other backend solutions like Kerberos
or AAA infrastructure, though a master student will try to take
care of this soon.

Thanks for the thorough review, I'll take care of the obvious nits and
edits asap. I'll reply to some of your comments here.

> s/so far specified//   (there won't be any other, no?)

right.

>> IANA acts as a registry for X-Types as described in Section 7, IANA
>> Considerations.  Initially, the registry contains the following
>> X-Types:
> 

Good catch, probably caused by a copy & paste error with hard referecens
in an earlier version.

> RFC1305 needs to be a normative reference.

OK.

>> padding: padding is required if the number of NSLP objects is
>> even. The padding field MUST be 16 bit set to 0.
> 
> Ambiguous. You mean that the padding is REQUIRED when even and that
> it MUST NOT be added when odd.

OK

> Does this mean that this document updates draft-ietf-nsis-qos-nslp?

Good question. I don't think so, since you perform additional
actions when implementing  draft-ietf-nsis-nslp-auth, so it
affects the implementation behavior, but not the basic
QoS NSLP protocol behavior.

> draft-ietf-nsis-nslp-natfw?

See above.

>> [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter,
>> "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, 
>> August 1998.
> 
>> [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
>> 3852, July 2004.
> 

Will double check.

Thanks,
 Roland

---

From: Lars Eggert <[email-masked]>
Date: Thu, 17 Jun 2010 11:35:44 +0800

Hi,

> is actually my preference), since there is no reason for code

AFAIK RFC3520 is not widely used. But it's too late for major changes like this. If we're unsure about how the authorization function should look like, we can punt on the work item, now that NSIS is only going for Experimental.

> QoS NSLP protocol behavior.

OK. So there is no interoperability issue between nodes that implement nslp-auth and ones that do not.

Lars

---

From: Jukka Manner <[email-masked]>
Date: Tue, 22 Jun 2010 07:59:27 +0300

Dear all,

there has been only one comment pre-WGLC on the document, and the AD review.

I would really like people to comment (even shortly), I'll give up to 
the end of the week for anyone to comment for or against the work to go 
forward.

Regards,
Jukka

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+451 2481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+451 2474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [email-masked]
Finland                           WWW:    www.comnet.tkk.fi

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 22 Jun 2010 13:21:03 +0200

Reads good to me. One comment:

    AB=00 ("Mandatory"): If the object is not understood, the entire
    message containing it MUST be rejected, and an error message sent
    back (usually of class/code "Protocol Error/Unknown object present").

"Protocol Error/Unknown object present" --> "Protocol Error/Object Type 
Error (subcode Unrecognised Object)"?

Xiaoming