Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary=Apple-Mail-3--545317990;
 protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4C0CA940.7080000@tkk.fi>
Date: Fri, 11 Jun 2010 16:15:08 +0300
Message-Id: <99B779C7-3319-465A-8D5D-70FDC8DBA163@nokia.com>
References: <20100515224502.402743A6A97@core3.amsl.com>
 <4C0CA940.7080000@tkk.fi>
To: Jukka Manner <jukka.manner@tkk.fi>
Cc: "nsis@ietf.org" <nsis@ietf.org>
Subject: [NSIS] AD review: draft-ietf-nsis-nslp-auth-02.txt
Precedence: list

--Apple-Mail-3--545317990
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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 =3D 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)



--Apple-Mail-3--545317990
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw
ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx
NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X
uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY
Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB
6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT
VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr
ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu
ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt
I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H
5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80
QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG
A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV
BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7
n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw
QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl
ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M
Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP
6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTEwMDYxMTEzMTUwOVowIwYJKoZIhvcNAQkEMRYEFG3ZGFJ7V4X8F9PvRqYcFcnnXah/MIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu
ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD
QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw
IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF
AASCAQCA59X01DLRPNTNpssFOssHyP1/6J6sUEXfMwAleqNTKpS87qLi2n96lEEoi/mX0V0DhT9N
nLCbU9PRa5ZYlT6zJpSHiOnC/g+79vpn5OG+Fv/+9XA68snPO9xB02RzNl691upHz2fjMt2IZCmk
W4wLvaMpGC3ckavDDAhGHBdVYuKhCC1PvHV+hEkHt9bJcKIqKJj5g46jGTC+3oPtoBXEd4e9u3w0
+kVpTqczt3b2WzdcE5+nnzkfHpqnjCMOUDG1FK63zfLoqfNdAKjBHRvUf+FC60rPeLkVSF3Yt7CY
4KHLmxBN++G7wJgv7J2XGUccI8PV2jc5Z5b/w6waAQ4PAAAAAAAA

--Apple-Mail-3--545317990--