From kwatsen@juniper.net Thu May 12 16:50:31 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF22E0780 for ; Thu, 12 May 2011 16:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGbIiBhmDqkq for ; Thu, 12 May 2011 16:50:30 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 72D2DE0767 for ; Thu, 12 May 2011 16:50:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTcxyReBcZgcQhxarWG5GtVcd2xItA3ZP@postini.com; Thu, 12 May 2011 16:50:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 12 May 2011 16:48:21 -0700 From: Kent Watsen To: "netconf@ietf.org" Date: Thu, 12 May 2011 16:48:17 -0700 Thread-Topic: draft-kwatsen-reverse-ssh submission for review Thread-Index: AcwQ/xEp+0sRUGfHRXuHqr1YP6Nbew== Message-ID: <84600D05C20FF943918238042D7670FD3E7E4A71DD@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_84600D05C20FF943918238042D7670FD3E7E4A71DDEMBX01HQjnprn_" MIME-Version: 1.0 Subject: [Netconf] draft-kwatsen-reverse-ssh submission for review X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 23:50:31 -0000 --_000_84600D05C20FF943918238042D7670FD3E7E4A71DDEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, I want to bring your attention to draft-kwatsen-reverse-ssh, which I just s= ubmitted for review. http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-00 Abstract This memo presents a technique for a SSH (Secure Shell) server to initiate the underlying TCP connection to the SSH client. This role reversal is necessary in cases where the SSH client would otherwise be unable to initiate an SSH connection to the SSH server, such as a device "calling home" on its first boot. After discussing with our chairs, Bert and Mehmet, as well as our AD Ronald= Bonica, it was decided to NOT bring this submission to the NETCONF WG for = consideration. Even though this submission is primarily to support NETCONF= , its impact is limited to SSH. Since the SECSH working group has concluded, the Security Area Directors, S= ean and Stephen, recommended posting an announcement regarding this individ= ual submission to the SAAG and IETF-SSH mailing lists, which I have done. I suspect that all the action regarding this submission will occur on those= lists. If the ideas presented in this submission are of interest to you, = please consider stating such on those lists as I imagine there will be an i= nitial amount of skepticism regarding its importance. Thanks, Kent --_000_84600D05C20FF943918238042D7670FD3E7E4A71DDEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
I want to bring your attention to draft-kwatsen-reverse-ssh, which I j= ust submitted for review.
 
 
 
   Abstract
 
      This memo presents a technique for a SS= H (Secure Shell) server to
      initiate the underlying TCP connection = to the SSH client.  This role
      reversal is necessary in cases where th= e SSH client would otherwise
      be unable to initiate an SSH connection= to the SSH server, such as a
      device "calling home" on its = first boot.
 
 
After discussing with our chairs, Bert and Mehmet, as well as our AD R= onald Bonica, it was decided to NOT bring this submission to the NETCONF WG= for consideration.  Even though this submission is primarily to suppo= rt NETCONF, its impact is limited to SSH.
 
Since the SECSH working group has concluded, the Security Area Directo= rs, Sean and Stephen, recommended posting an announcement regarding this in= dividual submission to the SAAG and IETF-SSH mailing lists, which I have do= ne.
 
I suspect that all the action regarding this submission will occur on = those lists.  If the ideas presented in this submission are of interes= t to you, please consider stating such on those lists as I imagine there wi= ll be an initial amount of skepticism regarding its importance.
 
Thanks,
Kent
 
 
 
 
 
 
 
 --_000_84600D05C20FF943918238042D7670FD3E7E4A71DDEMBX01HQjnprn_-- From lhotka@cesnet.cz Thu May 19 02:51:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D90E07A4 for ; Thu, 19 May 2011 02:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ew2FePiUOGw for ; Thu, 19 May 2011 02:51:14 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 12A77E079F for ; Thu, 19 May 2011 02:51:11 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 949182CDE057 for ; Thu, 19 May 2011 11:51:09 +0200 (CEST) From: Ladislav Lhotka Content-Type: multipart/signed; boundary=Apple-Mail-5--1073528487; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 19 May 2011 11:51:09 +0200 Message-Id: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> To: netconf@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 09:51:15 -0000 --Apple-Mail-5--1073528487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I realize this comes way too late in the 4741bis life cycle but I think = it should be clarified in Sec. 7.2 that the "operation" attribute in = actually belongs to the NETCONF namespace: OLD Elements in the subtree MAY contain an "operation" attribute. NEW Elements in the subtree MAY contain an "operation" attribute, which belongs to the NETCONF namespace defined in Section 3.1. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-5--1073528487 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTE5MDk1MTA5WjAjBgkqhkiG9w0BCQQxFgQU6DElFb9Fa4QuL5dvFLWkdDVdENIwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQA5iQer+FY+8xyiyj+yQ2PUjTgF VN9IeUNbcphlhbxhZiZwY36BRs+Pt1NTiZMzbVDNgwUuak0smHpfJhgGKklGTvMnGNZ4fEz4TxIl XyTPAHMZJE7c9jKMKbd+8muSObVKz0R1rRT44WDPcJbYCpQt2diw6kRO8rB8BEe9I2roTJOy1tCX BdAf+kzmjdzM2lR8dERItocpVshBS8iAHhoJzSfjOepYSRbHNd7SL6OIOBnK1uOp7QyM99fh20cB fbJI732/mfvp2RAID1vKSgR2zA3T3eRW3yvYn9SVAxCRzX7CQJiET4MYRLTGPlFnALcRGkmtxXXx Jip1F8jyNrecAAAAAAAA --Apple-Mail-5--1073528487-- From bertietf@bwijnen.net Thu May 19 03:15:48 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1BBE0795 for ; Thu, 19 May 2011 03:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=5.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz9JgIlnhyVa for ; Thu, 19 May 2011 03:15:48 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by ietfa.amsl.com (Postfix) with ESMTP id 42349E0727 for ; Thu, 19 May 2011 03:15:48 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QN0Gc-00089v-1u for netconf@ietf.org; Thu, 19 May 2011 12:15:43 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest178.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QN0Gb-0003bx-QY for netconf@ietf.org; Thu, 19 May 2011 12:15:42 +0200 Message-ID: <4DD4EDCD.6030406@bwijnen.net> Date: Thu, 19 May 2011 12:15:41 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd49337e6a7e85b353c53ae33b32ce56453 Subject: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 10:15:49 -0000 Sofar, it seems no-one has rected to the below. Please, please, we can hardly imagine no-one has any opinions on these topics. We are a WG, that means we need to discuss and try to come to consensus on these matters. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] Access Control Issues/Question Date: Fri, 01 Apr 2011 10:49:34 +0200 From: Bert Wijnen To: Netconf WG participants, Pls comment on this open issues that Martin presented in his suggested new/improved approach for NACM rule definitions at our meeting yesterday. The slides are here: http://tools.ietf.org/agenda/80/slides/netconf-1.pdf - Is two levels of nesting enough? - A common (?) use case is to define one rule­list for a task, and let some groups access it read-write, and some read-only. This is not directly supported – you would need to define two different rule-lists, e.g. routing- admin and routing-read. By moving the allowed­groups check from the rule to the rule­list, we loose some flexibility. If we really need special handling of a rule for some group, this rule needs to be defined in a separate rule-list. - Would it be useful with any objects to help debug a NACM configuration? - rpc get-rules group-name ---> list of rules - rpc check-path group-name path ---> rule execution trace Bert and Mehmet From mehmet.ersue@nsn.com Thu May 19 05:57:07 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D887E078D for ; Thu, 19 May 2011 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK8PO9j-pSjG for ; Thu, 19 May 2011 05:57:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A65CBE0789 for ; Thu, 19 May 2011 05:57:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4JCv3XJ016243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 May 2011 14:57:03 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4JCv1hY016857 for ; Thu, 19 May 2011 14:57:02 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 May 2011 14:57:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 May 2011 14:57:00 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64021B94BF@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] NETCONF Protocol Interoperability Event around QuebecMeeting ? Thread-Index: AcwHSccS7hzjmJk6QeiIKbd8lUObVQO2dMkg References: <80A0822C5E9A4440A5117C2F4CD36A6401E11409@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 19 May 2011 12:57:01.0774 (UTC) FILETIME=[3EF466E0:01CC1624] Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around QuebecMeeting ? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 12:57:07 -0000 Hi All, it seems there is no sufficient interest on a NETCONF=20 Protocol Interoperability Event. Thank you to those few=20 guys who send us their comments. We go into a silent mode now, until we here some concrete=20 interest for such an event with the goal to get NETCONF=20 documents into draft standard status. Mehmet & Bert > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Bert Wijnen (IETF) > Sent: Saturday, April 30, 2011 5:17 PM > To: netconf > Subject: Re: [Netconf] NETCONF Protocol Interoperability Event around > QuebecMeeting ? >=20 > We (WG chairs) made a little mistake. WE did not > put a deadline for responsesn. >=20 > Sofar, we have only had one response (albeit a positive one) > to our poll for interest in an interoperability event around the > next IETF meeting. >=20 > If we do not get (at least 2, preferably more) more positive > responses by May 10, then we won't have such an event. >=20 > Your WG chairs. > Bert and Mehmet >=20 > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "netconf" > Cc: "ext Romascanu, Dan (Dan)" ; > > Sent: Sunday, April 03, 2011 9:35 AM > Subject: NETCONF Protocol Interoperability Event around Quebec Meeting > ? >=20 >=20 > Dear NETCONF WG, >=20 > in the IETF80 NETCONF session it has been discussed whether a NETCONF > protocol interoperability event should be organized to take place > around > the Quebec meeting. > The NETCONF interoperability event would be helpful to get our Proposed > Standards to the Draft Standard status. >=20 > The chairs would like to sense of the WG for the level of interest of > the implementers on such an interop event. >=20 > The focus in the interoperability event would be on following RFCs: > - draft-ietf-netconf-4741bis (in RFC Ed Queue), > - draft-ietf-netconf-rfc4742bis (in RFC Ed Queue), > - RFC 5277 - NETCONF Event Notifications, > - RFC 6022 - YANG Module for NETCONF Monitoring, > - RFC 5717 - Partial Lock RPC for NETCONF, > - draft-ietf-netconf-with-defaults (in RFC Ed Queue). >=20 >=20 > The questions we would like to clarify are in the first step: >=20 > - Who has which implementations ready to test by July 1st, 2011? > - Who would come with implementations and participate if the event > gets > organised? > - Who can provide content for testing (i.e. YANG modules e.g. > Monitoring)? > - Who would be willing to prepare test cases? >=20 > Please state your interest and opinion on the interop event to the > chairs directly. >=20 > Mehmet & Bert >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mbadra@gmail.com Tue May 24 06:47:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91484E0747 for ; Tue, 24 May 2011 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDkntwwPAK1s for ; Tue, 24 May 2011 06:47:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED95BE06BA for ; Tue, 24 May 2011 06:47:14 -0700 (PDT) Received: by vxg33 with SMTP id 33so5935327vxg.31 for ; Tue, 24 May 2011 06:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=z9ci7pjvVIF3xAT97hp5qoF+xc1vpUmAlVNS7re/Swo=; b=uaAaf8wRK+o/UVqQt7x7a2Tqw5lfzxYuQxAeF0ptu0nSqrwh57m/tP2yrERuwYemce pOtSI8UVQQWXjtgrXAk9qdrGZJpu1zN0+ThtqUcAbxRlmoQ+6dm5JfsyRSibkG4rIc6Y iAbUlJtsdiJ60rN9Hgvbj58svheL5F3GvMK0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TeoXEVFqYhhDjHmKdwJ1T/uIZWiH4Su7CE6AMBDdx21cgL2foGpFj+Zu0ywxhbwBow uUrkkhULqkc87Lz9mX4vLOog049kbHfDbJlM7CSO3uxp+m7aObutdLHJ43snVNuhUl27 XIIrKaVVaoQ9CiwVa2kzMrt0LILvuWblFkBEY= MIME-Version: 1.0 Received: by 10.52.0.130 with SMTP id 2mr2107772vde.180.1306244834417; Tue, 24 May 2011 06:47:14 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Tue, 24 May 2011 06:47:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 May 2011 15:47:14 +0200 Message-ID: From: Badra To: netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:47:15 -0000 Dear all, NETCONF over TLS document (RFC5539) update needs to support and fulfill (additional to the introduction of the Chunked Framing) the requirements on the username handling defined in 4741bis. For the Chunked Framing, I will bring the same way being proposed by NETCONF over SSH document. Since the only authentication mechanism being defined by RFC5539 is based on certificates, so I would propose the following (it borrows text from rfc5216): In NETCONF over TLS, the username is determined from the subject or subjectAltName fields in the manager's certificates. For details, see Section 4.1.2.6 of [RFC5280]. Where the subjectAltName field is present in the certificate, the username MUST be set to the contents of the subjectAltName. If subject naming information is present only in the subjectAltName extension of certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Where the username represents a host, a subjectAltName of type dnsName SHOULD be present in the manager certificate. Where the username represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). If subject naming information is present only in the subject name field of the manager's certificate and the username represents a host or device, the subject name field SHOULD contain a CommonName (CN) RDN or serialNumber RDN. If subject naming information is present only in the subject name field of the manager's certificate, then the subject name field SHOULD contain a CN RDN or serialNumber RDN. It is possible for more than one subjectAltName field to be present in the manager's certificate in addition to an empty or non-empty subject distinguished name. Implementations of this document SHOULD export all the subjectAltName fields and the non-empty subject distinguished name field. All of the exported fields are considered valid. The username provided by the implementation of this document will be made available to the NETCONF message layer as the NETCONF username without modification. If the username does not comply to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not representable in XML, the TLS session MUST be dropped. Any transformations applied to the authenticated identity of the TLS client made by the TLS server (e.g., via authentication services or mappings to system accounts) are outside the scope of this document. Comments? Best regards Badra From j.schoenwaelder@jacobs-university.de Tue May 24 07:23:04 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B79E0741 for ; Tue, 24 May 2011 07:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq2wNayjVf7Y for ; Tue, 24 May 2011 07:23:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2BEE06AF for ; Tue, 24 May 2011 07:23:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E61620D25; Tue, 24 May 2011 16:23:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eyzCNU6R-cLL; Tue, 24 May 2011 16:23:01 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DCA420D23; Tue, 24 May 2011 16:23:01 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 6065A18B53E4; Tue, 24 May 2011 16:23:01 +0200 (CEST) Date: Tue, 24 May 2011 16:23:01 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Badra , netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:23:04 -0000 On Tue, May 24, 2011 at 03:47:14PM +0200, Badra wrote: > Where the subjectAltName field is present in the certificate, the username > MUST be set to the contents of the subjectAltName. If subject naming > information is present only in the subjectAltName extension of certificate, > then the subject field MUST be an empty sequence and the subjectAltName > extension MUST be critical. What does "MUST be critical" mean? [...] > It is possible for more than one subjectAltName field to be present in the > manager's certificate in addition to an empty or non-empty subject > distinguished name. Implementations of this document SHOULD export all the > subjectAltName fields and the non-empty subject distinguished name field. > All of the exported fields are considered valid. Export to whom? If there are multiple subjectAltNames, how do you choose the username? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Tue May 24 08:40:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60470E073C for ; Tue, 24 May 2011 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.305 X-Spam-Level: X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBMRGAWngLQy for ; Tue, 24 May 2011 08:40:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41DD1E0671 for ; Tue, 24 May 2011 08:40:49 -0700 (PDT) Received: by vws12 with SMTP id 12so6076563vws.31 for ; Tue, 24 May 2011 08:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KLO5oJSUTz2tbG0IyaKYdyROHM15OrCh/61HZoD5sIY=; b=l2Ef0dUqJL28Oe13AxcYBQizsyRSL4n3Mf7ZxJUOQr1hwrRO26OisrhZu/Fdeorvy5 hclgUyNP72RC6HvaLWGgaQaGAMawQWiCn2jpBtdy1wx9iH3n8DAJAgvBIG2omltb5lNd m4LPizoAa2Gd9NowGAq3tVXi+X+lbPN3O3mKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=XiJx1psk182qhmIbHbSBWHpJ7eVUEH6/oi7CYN4u7fC6jRkbWIeQYOat+PujdrUE7e KqSsIH8VwZVuOxa3kQTyKLtJIFGl40M+YQrP18U5tzBcIBZ8rpSGOl4MRD0TK8TWgoH9 V/QSzlnPJ+tFc05khlz3O1DDfdMfriQSjvMzw= MIME-Version: 1.0 Received: by 10.220.71.196 with SMTP id i4mr1155919vcj.134.1306251648449; Tue, 24 May 2011 08:40:48 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Tue, 24 May 2011 08:40:48 -0700 (PDT) In-Reply-To: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> Date: Tue, 24 May 2011 17:40:48 +0200 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:40:50 -0000 Hi, >> Where the subjectAltName field is present in the certificate, the username >> MUST be set to the contents of the subjectAltName. If subject naming >> information is present only in the subjectAltName extension of >> certificate, >> then the subject field MUST be an empty sequence and the subjectAltName >> extension MUST be critical. > > What does "MUST be critical" mean? The following text explains the meaning of "critical": (extracted from http://wiki.cacert.org/VhostTaskForce). When an implementation processing a certificate does not recognize an extension, if the criticality flag is FALSE, it may ignore that extension. If the criticality flag is TRUE, unrecognized extensions shall cause the structure to be considered invalid, i.e. in a certificate, an unrecognized critical extension would cause validation of a signature using that certificate to fail. When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag. >> It is possible for more than one subjectAltName field to be present in the >> manager's certificate in addition to an empty or non-empty subject >> distinguished name. Implementations of this document SHOULD export all >> the >> subjectAltName fields and the non-empty subject distinguished name field. >> All of the exported fields are considered valid. > > Export to whom? If there are multiple subjectAltNames, how do you > choose the username? Export to the NETCONF message layer If multiple subjectAltNames are presented, all of them are exported to the NETCONF message layer. A match in any one of the exported subjectAltNames is considered acceptable Best regards, Badra From j.schoenwaelder@jacobs-university.de Tue May 24 08:44:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828CE0730 for ; Tue, 24 May 2011 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqn31yE2okA1 for ; Tue, 24 May 2011 08:44:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2D05DE0671 for ; Tue, 24 May 2011 08:44:04 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8712020D3D; Tue, 24 May 2011 17:44:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2VV+UrC264T0; Tue, 24 May 2011 17:44:02 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C92020CE4; Tue, 24 May 2011 17:44:02 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 0EE8418B58B4; Tue, 24 May 2011 17:44:02 +0200 (CEST) Date: Tue, 24 May 2011 17:44:02 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Badra , netconf@ietf.org References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:44:05 -0000 On Tue, May 24, 2011 at 05:40:48PM +0200, Badra wrote: > Hi, > > >> Where the subjectAltName field is present in the certificate, the username > >> MUST be set to the contents of the subjectAltName. If subject naming > >> information is present only in the subjectAltName extension of > >> certificate, > >> then the subject field MUST be an empty sequence and the subjectAltName > >> extension MUST be critical. > > > > What does "MUST be critical" mean? > > The following text explains the meaning of "critical": > (extracted from http://wiki.cacert.org/VhostTaskForce). > > When an implementation processing a certificate does not recognize an > extension, > if the criticality flag is FALSE, it may ignore that extension. If the > criticality flag is > TRUE, unrecognized extensions shall cause the structure to be > considered invalid, > i.e. in a certificate, an unrecognized critical extension would cause > validation of a > signature using that certificate to fail. When a certificate-using > implementation > recognizes and is able to process an extension, then the certificate-using > implementation shall process the extension regardless of the value of > the criticality > flag. Is this the normative reference for this?? > >> It is possible for more than one subjectAltName field to be present in the > >> manager's certificate in addition to an empty or non-empty subject > >> distinguished name. Implementations of this document SHOULD export all > >> the > >> subjectAltName fields and the non-empty subject distinguished name field. > >> All of the exported fields are considered valid. > > > > Export to whom? If there are multiple subjectAltNames, how do you > > choose the username? > > > Export to the NETCONF message layer > > If multiple subjectAltNames are presented, all of them are exported to > the NETCONF message layer. A match in any one of the exported > subjectAltNames is considered acceptable I do not think RFC4741bis provides that service to the transport. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Tue May 24 08:55:24 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37F4E0766 for ; Tue, 24 May 2011 08:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKxv-wQcd-sV for ; Tue, 24 May 2011 08:55:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83CC2E0756 for ; Tue, 24 May 2011 08:55:23 -0700 (PDT) Received: by vws12 with SMTP id 12so6092815vws.31 for ; Tue, 24 May 2011 08:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=P/Pay/y+u1b2HsLejAAX97yXgv2DbnRk1jK2cawBgFQ=; b=aeTtoOpIDpkrOwijrwXE6uYhi0sKBB7IRR+6AtS0bGpb6iDDC/jIhIVmIhFZLl1iZr zZWx2tgpbko/aDXfWVNW8v1SzxtrDUcin0dNocnB2EDf9rZaUT0pdmFrzl9fXWezGnd8 d3XLYUyyeb3qXk3W8CTSjcrr8dOTwgPv+T6Kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Vo2NxoTUKv6QKarGEM9rWnngolZXV+L1RYHvsWb64kq5Gv4wRdZWyT4FH6G4CT9/7n PeKbJqiAdkSIG+0nXSgZPEOg7n4JISaWW6E2v6dTxMxyY17yEl9I/hAExZnzl/z8gPU3 9U8eM69OnDJ3kes1aHJvIkTK8L73TfQrbLOiU= MIME-Version: 1.0 Received: by 10.220.71.196 with SMTP id i4mr1160927vcj.134.1306252522858; Tue, 24 May 2011 08:55:22 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Tue, 24 May 2011 08:55:22 -0700 (PDT) In-Reply-To: <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> Date: Tue, 24 May 2011 17:55:22 +0200 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , netconf@ietf.org Content-Type: multipart/alternative; boundary=0016e64604209ca94604a4079ddc Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:55:24 -0000 --0016e64604209ca94604a4079ddc Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 24, 2011 at 5:44 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, May 24, 2011 at 05:40:48PM +0200, Badra wrote: > > Hi, > > > > >> Where the subjectAltName field is present in the certificate, the > username > > >> MUST be set to the contents of the subjectAltName. If subject naming > > >> information is present only in the subjectAltName extension of > > >> certificate, > > >> then the subject field MUST be an empty sequence and the > subjectAltName > > >> extension MUST be critical. > > > > > > What does "MUST be critical" mean? > > > > The following text explains the meaning of "critical": > > (extracted from http://wiki.cacert.org/VhostTaskForce). > > > > When an implementation processing a certificate does not recognize an > > extension, > > if the criticality flag is FALSE, it may ignore that extension. If the > > criticality flag is > > TRUE, unrecognized extensions shall cause the structure to be > > considered invalid, > > i.e. in a certificate, an unrecognized critical extension would cause > > validation of a > > signature using that certificate to fail. When a certificate-using > > implementation > > recognizes and is able to process an extension, then the > certificate-using > > implementation shall process the extension regardless of the value of > > the criticality > > flag. > > Is this the normative reference for this?? > > NO, you have section 4.2 of RFC5280 ... Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. > > >> It is possible for more than one subjectAltName field to be present in > the > > >> manager's certificate in addition to an empty or non-empty subject > > >> distinguished name. Implementations of this document SHOULD export > all > > >> the > > >> subjectAltName fields and the non-empty subject distinguished name > field. > > >> All of the exported fields are considered valid. > > > > > > Export to whom? If there are multiple subjectAltNames, how do you > > > choose the username? > > > > > > Export to the NETCONF message layer > > > > If multiple subjectAltNames are presented, all of them are exported to > > the NETCONF message layer. A match in any one of the exported > > subjectAltNames is considered acceptable > > I do not think RFC4741bis provides that service to the transport. Would it workif we export them one by one till a match is there? Have you any other proposal for exporting multiple subjectAltNames? If not, we shall be restricted to a singlesubjectAltName Best regards Badra --0016e64604209ca94604a4079ddc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, May 24, 2011 at 5:44 PM, Juergen Schoenw= aelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, May 24, 2011 at 05:40:48PM +0200, Badra wrote:> Hi,
>
> >> Where the subjectAltName field is presen= t in the certificate, the username
> >> MUST be set to the cont= ents of the subjectAltName. If subject naming
> >> information is present only in the subjectAltName extension o= f
> >> certificate,
> >> then the subject field MUS= T be an empty sequence and the subjectAltName
> >> extension MU= ST be critical.
> >
> > What does "MUST be critical" mean?
>=
> The following text explains the meaning of "critical":> (extracted from http://wiki.cacert.org/VhostTaskForce).
>
> When an implementation processing a certificate does not recog= nize an
> extension,
> if the criticality flag is FALSE, it may= ignore that extension. If the
> criticality flag is
> TRUE, un= recognized extensions shall cause the structure to be
> considered invalid,
> i.e. in a certificate, an unrecognized cri= tical extension would cause
> validation of a
> signature using= that certificate to fail. When a certificate-using
> implementation<= br> > recognizes and is able to process an extension, then the certificate-u= sing
> implementation shall process the extension regardless of the v= alue of
> the criticality
> flag.

Is this th= e normative reference for this??

=A0
=A0
NO, you have section 4.2 of RFC5280
... Each extension in a
=A0=A0 certificate is designated as either = critical or non-critical.=A0 A
=A0=A0 certificate-using system MUST reje= ct the certificate if it encounters
=A0=A0 a critical extension it does = not recognize or a critical extension
=A0=A0 that contains information that it cannot process.=A0 A non-critical<= br>=A0=A0 extension MAY be ignored if it is not recognized, but MUST be
= =A0=A0 processed if it is recognized.
=A0
> >> It is possible for more than one subjectAlt= Name field to be present in the
> >> manager's certificate = in addition to an empty or non-empty subject
> >> distinguished= name. =A0Implementations of this document SHOULD export all
> >> the
> >> subjectAltName fields and the non-empty = subject distinguished name field.
> >> All of the exported fiel= ds are considered valid.
> >
> > Export to whom? If there= are multiple subjectAltNames, how do you
> > choose the username?
>
>
> Export to the NETCON= F message layer
>
> If multiple subjectAltNames are presented, = all of them are exported to
> the NETCONF message layer. A match in a= ny one of the exported
> subjectAltNames is considered acceptable

I do not think R= FC4741bis provides that service to the transport.
=A0
Would it workif we export them one by one till a match is there?
Have you any other proposal for exporting multiple subjectAltNames?
If not, we shall be restricted to a singlesubjectAltName
=A0
Best regards
Badra
--0016e64604209ca94604a4079ddc-- From j.schoenwaelder@jacobs-university.de Tue May 24 09:01:32 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA2E0773 for ; Tue, 24 May 2011 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2jdRIvBpAej for ; Tue, 24 May 2011 09:01:31 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85BE0764 for ; Tue, 24 May 2011 09:01:31 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 048EF20D01; Tue, 24 May 2011 18:01:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j1wcjlka8uyR; Tue, 24 May 2011 18:01:30 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6639C20CF5; Tue, 24 May 2011 18:01:30 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 57DFA18B5964; Tue, 24 May 2011 18:01:30 +0200 (CEST) Date: Tue, 24 May 2011 18:01:30 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110524160130.GB1477@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Badra , netconf@ietf.org References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:01:32 -0000 On Tue, May 24, 2011 at 05:55:22PM +0200, Badra wrote: > > NO, you have section 4.2 of RFC5280 > ... Each extension in a > certificate is designated as either critical or non-critical. A > certificate-using system MUST reject the certificate if it encounters > a critical extension it does not recognize or a critical extension > that contains information that it cannot process. A non-critical > extension MAY be ignored if it is not recognized, but MUST be > processed if it is recognized. A pointer to that at the right place would be bhighly appreciated. > > > If multiple subjectAltNames are presented, all of them are exported to > > > the NETCONF message layer. A match in any one of the exported > > > subjectAltNames is considered acceptable > > > > I do not think RFC4741bis provides that service to the transport. > > Would it workif we export them one by one till a match is there? > Have you any other proposal for exporting multiple subjectAltNames? > If not, we shall be restricted to a singlesubjectAltName There currently is no such loop iterating over a set of usernames. So either RFC 4741bis needs to provide this functionality by allowing transports to supply (ordered?) sets of usernames or the TLS transport has to figure out how to select the one and only username. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Tue May 24 09:09:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDBBE073D for ; Tue, 24 May 2011 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sVXtetrA73z for ; Tue, 24 May 2011 09:09:14 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9CB5E06A3 for ; Tue, 24 May 2011 09:09:14 -0700 (PDT) Received: by vws12 with SMTP id 12so6109418vws.31 for ; Tue, 24 May 2011 09:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=rY6EOGjK31Y+8DSiWUzblefWv3GAOBJkMEg4vSCgMbg=; b=AP5otZd3GhVEb1ad3QvuRqPy0uZvTodmWLSZeIk1q4RD2LeZLUVKcDF1uoj1Hb7Tlb Mk19QIWSS2zZMM27etpA2gNUV2ynHnNEhCxrTEV+CnchzoeGPjQNIvBPaw4j0+cbATdB AQ4orfG9DRsWANsOqkL67idpYPLk0qnVnemCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Nz+GXY0rR+jgXuFCuPfQLr/U2PQI6mTFRLNe+Oy1ZJ8Q9fdqmV6HRvUCgsU7Ep+NSx pxyxsAbzCP0OxU2V6xfY4t3CU6NQ6KC364TdvxqRLhKxdWU/HgcJhFcQ4ALu8WfbjkI7 jmK3hz8FkcXP5jLmCiW5lZOcSbbxozZ5Pti4Y= MIME-Version: 1.0 Received: by 10.220.71.196 with SMTP id i4mr1165662vcj.134.1306253353969; Tue, 24 May 2011 09:09:13 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Tue, 24 May 2011 09:09:13 -0700 (PDT) In-Reply-To: <20110524160130.GB1477@elstar.jacobs.jacobs-university.de> References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> <20110524160130.GB1477@elstar.jacobs.jacobs-university.de> Date: Tue, 24 May 2011 18:09:13 +0200 Message-ID: From: Badra To: Juergen Schoenwaelder , Badra , netconf@ietf.org Content-Type: multipart/alternative; boundary=0016e646042026670104a407cf56 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:09:15 -0000 --0016e646042026670104a407cf56 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 24, 2011 at 6:01 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, May 24, 2011 at 05:55:22PM +0200, Badra wrote: > > > > NO, you have section 4.2 of RFC5280 > > ... Each extension in a > > certificate is designated as either critical or non-critical. A > > certificate-using system MUST reject the certificate if it encounters > > a critical extension it does not recognize or a critical extension > > that contains information that it cannot process. A non-critical > > extension MAY be ignored if it is not recognized, but MUST be > > processed if it is recognized. > > A pointer to that at the right place would be bhighly appreciated. OK > > > > If multiple subjectAltNames are presented, all of them are exported > to > > > > the NETCONF message layer. A match in any one of the exported > > > > subjectAltNames is considered acceptable > > > > > > I do not think RFC4741bis provides that service to the transport. > > > > Would it workif we export them one by one till a match is there? > > Have you any other proposal for exporting multiple subjectAltNames? > > If not, we shall be restricted to a singlesubjectAltName > > There currently is no such loop iterating over a set of usernames. So > either RFC 4741bis needs to provide this functionality by allowing > transports to supply (ordered?) sets of usernames or the TLS transport > has to figure out how to select the one and only username. IMO, it would be better to specify it by RFC 4741bis. Like that, all transports could rely on a common way of looping over a set of usernames Best regards Badra --0016e646042026670104a407cf56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 24, 2011 at 6:01 PM= , Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, May 24, 2011 at 05:55:22PM +0200, Badra wrote:>
> NO, you have section 4.2 of RFC5280
> ... Each extensio= n in a
> =A0 =A0certificate is designated as either critical or non-c= ritical. =A0A
> =A0 =A0certificate-using system MUST reject the certificate if it enco= unters
> =A0 =A0a critical extension it does not recognize or a criti= cal extension
> =A0 =A0that contains information that it cannot proce= ss. =A0A non-critical
> =A0 =A0extension MAY be ignored if it is not recognized, but MUST be> =A0 =A0processed if it is recognized.

A pointer to that= at the right place would be bhighly appreciated.
=A0
=A0
OK
=A0
> > > If multiple subjectAltNames are presented,= all of them are exported to
> > > the NETCONF message layer. A= match in any one of the exported
> > > subjectAltNames is cons= idered acceptable
> >
> > I do not think RFC4741bis provides that service to t= he transport.
>
> Would it workif we export them one by one til= l a match is there?
> Have you any other proposal for exporting multi= ple subjectAltNames?
> If not, we shall be restricted to a singlesubjectAltName

= There currently is no such loop iterating over a set of usernames. So
ei= ther RFC 4741bis needs to provide this functionality by allowing
transpo= rts to supply (ordered?) sets of usernames or the TLS transport
has to figure out how to select the one and only username.
=A0
=A0
IMO, it would be better to=A0specify it by=A0RFC 4741bis. Like that, a= ll transports could
rely on a common way of looping over a set of usernames
=A0
Best regards
Badra
--0016e646042026670104a407cf56-- From j.schoenwaelder@jacobs-university.de Tue May 24 10:21:57 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8594813000E for ; Tue, 24 May 2011 10:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGgSDtajBvd8 for ; Tue, 24 May 2011 10:21:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AD13000C for ; Tue, 24 May 2011 10:21:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 054CC20C5D; Tue, 24 May 2011 19:21:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0OUHLQQbwPbq; Tue, 24 May 2011 19:21:55 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25B8220C5C; Tue, 24 May 2011 19:21:55 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 1565A18B5BAB; Tue, 24 May 2011 19:21:55 +0200 (CEST) Date: Tue, 24 May 2011 19:21:55 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110524172154.GA1714@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Badra , netconf@ietf.org References: <20110524142301.GF938@elstar.jacobs.jacobs-university.de> <20110524154401.GA1477@elstar.jacobs.jacobs-university.de> <20110524160130.GB1477@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:21:57 -0000 On Tue, May 24, 2011 at 06:09:13PM +0200, Badra wrote: > > There currently is no such loop iterating over a set of usernames. So > > either RFC 4741bis needs to provide this functionality by allowing > > transports to supply (ordered?) sets of usernames or the TLS transport > > has to figure out how to select the one and only username. > > IMO, it would be better to specify it by RFC 4741bis. Like that, all > transports could rely on a common way of looping over a set of > usernames It might be important to note that RFC4741bis is in the RFC editor queue - so procedurally, such a change to NETCONF is not likely going to happen any time soon. But that said, the usage of the username is really in the access control part of NETCONF, which is a WG I-D. But then this document also does not provide many details, but it says also: Once session establishment is completed, and a user identity has been authenticated, the NETCONF transport layer reports the username and a possibly empty set of group names associated with the user to the NETCONF server. [...] RFC4741bis does not talk about group names as far as I can tell... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue May 24 10:27:51 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3DCE06AE for ; Tue, 24 May 2011 10:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4cKHI0ufejN for ; Tue, 24 May 2011 10:27:50 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7123BE067F for ; Tue, 24 May 2011 10:27:50 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTdvqlXERLP+yDmq44hxOfEPuw528FObE@postini.com; Tue, 24 May 2011 10:27:50 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 24 May 2011 10:24:41 -0700 From: Kent Watsen To: Badra , "netconf@ietf.org" Date: Tue, 24 May 2011 10:24:38 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwaGRtSBiN8oIFdQZ2Y0LS2cACgRwAGhz8A Message-ID: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:27:51 -0000 Placing X.500 into the client's certificate is interesting, but raises the = following questions: 1. Since devices are unlikely to know how to map any field other than CN=3D= , should the draft explicit state that the other fields (C, O, OU, etc.) will be = ignored? 2. Should the draft say that the CN should be a uid (i.e. kwatsen) instead = of a full name (i.e. Kent Watsen)? 3. How would the TLS server authenticate the TLS client's certificate? Wil= l the certificate be signed by a CA the TLS server is previously configured to trust? 4. If the TLS client's certificate can be signed by a CA, would it make sen= se to define a=20 field to encode a group assignment? For instance, the Netconf server ma= y not know who "kwatsen" is, but it sees that a CA the NetConf server trusts has stated= that "kwatsen" is a member of the "admin" group... PS: I find the NetConf Manager/Agent terminology in 5539 confusing - would = it be easier to=20 always spell out TLS Client/Server and NetConf client/server? Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Badra Sent: Tuesday, May 24, 2011 9:47 AM To: netconf@ietf.org Subject: [Netconf] Updating NETCONF over TLS document (RFC5539) Dear all, NETCONF over TLS document (RFC5539) update needs to support and fulfill (additional to the introduction of the Chunked Framing) the requirements on the username handling defined in 4741bis. For the Chunked Framing, I will bring the same way being proposed by NETCONF over SSH document. Since the only authentication mechanism being defined by RFC5539 is based on certificates, so I would propose the following (it borrows text from rfc5216): In NETCONF over TLS, the username is determined from the subject or subjectAltName fields in the manager's certificates. For details, see Section 4.1.2.6 of [RFC5280]. Where the subjectAltName field is present in the certificate, the username MUST be set to the contents of the subjectAltName. If subject naming information is present only in the subjectAltName extension of certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Where the username represents a host, a subjectAltName of type dnsName SHOULD be present in the manager certificate. Where the username represent= s a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used. If a dnsName or rfc822Name are not available, other field types (for example, a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). If subject naming information is present only in the subject name field of the manager's certificate and the username represents a host or device, the subject name field SHOULD contain a CommonName (CN) RDN or serialNumber RDN. If subject naming information is present only in the subject name field of the manager's certificate, then the subject name field SHOULD contain a CN RDN or serialNumber RDN. It is possible for more than one subjectAltName field to be present in the manager's certificate in addition to an empty or non-empty subject distinguished name. Implementations of this document SHOULD export all the subjectAltName fields and the non-empty subject distinguished name field. All of the exported fields are considered valid. The username provided by the implementation of this document will be made available to the NETCONF message layer as the NETCONF username without modification. If the username does not comply to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not representable in XML, the TLS session MUST be dropped. Any transformations applied to the authenticated identity of the TLS client made by the TLS server (e.g., via authentication services or mappings to system accounts) are outside the scope of this document. Comments? Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue May 24 10:41:04 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBEEE0776 for ; Tue, 24 May 2011 10:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEhyRpJWov0v for ; Tue, 24 May 2011 10:41:04 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id A2C89E073D for ; Tue, 24 May 2011 10:41:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTdvtrjO0SYvk3Gu8ZXYfOd/6ClSCS2nZ@postini.com; Tue, 24 May 2011 10:41:03 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 24 May 2011 10:35:44 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p4OHZhv64684; Tue, 24 May 2011 10:35:43 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p4OHBFKV067255; Tue, 24 May 2011 17:11:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201105241711.p4OHBFKV067255@idle.juniper.net> To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> Date: Tue, 24 May 2011 13:11:15 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 17:41:04 -0000 Kent Watsen writes: >PS: I find the NetConf Manager/Agent terminology in 5539 confusing - would it be easier >to always spell out TLS Client/Server and NetConf client/server? Amen. We avoid the terms "manager" and "agent" in all the other NETCONF-related specs. I'm surprised to see them here. Thanks, Phil From kwatsen@juniper.net Tue May 24 13:48:14 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48581E0786 for ; Tue, 24 May 2011 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2Lkexf6sE8Y for ; Tue, 24 May 2011 13:48:13 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8D551E0775 for ; Tue, 24 May 2011 13:48:13 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwZiytlNzY23abDbBEinNzaz2uhrPKd@postini.com; Tue, 24 May 2011 13:48:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 24 May 2011 13:46:48 -0700 From: Kent Watsen To: Ladislav Lhotka , "netconf@ietf.org" Date: Tue, 24 May 2011 13:46:42 -0700 Thread-Topic: [Netconf] namespace of "operation" attribute Thread-Index: AcwWClBQmB8VtCIkS4a/fGTeeIfk3AESHWeg Message-ID: <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> References: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> In-Reply-To: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:48:14 -0000 Oh, but let's not forget these two 4741bisbis issues (http://www.ietf.org/m= ail-archive/web/netconf/current/msg06734.html) ;) Actually, I posted a "solution" for the second issue (http://www.ietf.org/m= ail-archive/web/netconf/current/msg06744.html), though it's not very nice f= or either clients or servers... K. -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Ladislav Lhotka Sent: Thursday, May 19, 2011 5:51 AM To: netconf@ietf.org Subject: [Netconf] namespace of "operation" attribute Hi, I realize this comes way too late in the 4741bis life cycle but I think it = should be clarified in Sec. 7.2 that the "operation" attribute in actually belongs to the NETCONF namespace: OLD Elements in the subtree MAY contain an "operation" attribute. NEW Elements in the subtree MAY contain an "operation" attribute, whic= h belongs to the NETCONF namespace defined in Section 3.1. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbadra@gmail.com Tue May 24 14:20:50 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD29BE07D5 for ; Tue, 24 May 2011 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EAEcUO5KDXs for ; Tue, 24 May 2011 14:20:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E586E07BA for ; Tue, 24 May 2011 14:20:49 -0700 (PDT) Received: by vws12 with SMTP id 12so6413000vws.31 for ; Tue, 24 May 2011 14:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7I1IU7DuZ1YiVkiEnNkZxJzAYgou83d16JQio6GO+tA=; b=vyQGC4rrKCqPkTsksshC6OhNnDcRnI8dyvjXLKGGvzCJQiPzZlVMYcYhnF3gQGEIkN 3LkEN7xNy1AWCCW6etSz7qyJHc4uNNov9o40Q3ws7w3uZ1w+3fON+XyS6031LowxvMUE mVlPxlnttCZrWz7+ELHCssUiJ34gePzaUPFHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jCbt3SwW3tjQoW4f1yY5qllzYK8UMzXK0B2dVMkM0JHAD3v06TgO14h3rXBuzaC/yP 9dFRI7WSe6ZSbb8x2UOBvHLZWE/B224Q+9UWly+dnu4iQlP3ffg/fEqPW1n1IHirUCFH HFndteN4fFgJEdud4hD0oTf6fGlaecLMC+yLs= MIME-Version: 1.0 Received: by 10.220.79.228 with SMTP id q36mr1265130vck.99.1306272048684; Tue, 24 May 2011 14:20:48 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Tue, 24 May 2011 14:20:48 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> Date: Tue, 24 May 2011 23:20:48 +0200 Message-ID: From: Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=0016e647640a711f1804a40c294d Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:20:50 -0000 --0016e647640a711f1804a40c294d Content-Type: text/plain; charset=ISO-8859-1 Hi Kent, On Tue, May 24, 2011 at 7:24 PM, Kent Watsen wrote: > Placing X.500 into the client's certificate is interesting, but raises the > following questions: > > > 1. Since devices are unlikely to know how to map any field other than > CN=, should > the draft explicit state that the other fields (C, O, OU, etc.) will be > ignored? > > 2. Should the draft say that the CN should be a uid (i.e. kwatsen) instead > of a full name > (i.e. Kent Watsen)? > > It should do, What about adding after the " Where it is non-empty, the subject name field MUST contain an X.500 .......... contain a CN RDN or serialNumber RDN. Implementations of this specification MUST be prepared to ignore the following standard attribute types in issuer and subject names: * country, * organization, * organizational unit, * distinguished name qualifier, * state or province name, * serial number. The common name SHOULD be a uid (e.g., "kwatsen"), insteqd of full name (e.g. "Kent Wasten"). 3. How would the TLS server authenticate the TLS client's certificate? Will > the certificate > be signed by a CA the TLS server is previously configured to trust? > > This is beyond TLS, isn't? It is based on PKI as you described. > 4. If the TLS client's certificate can be signed by a CA, would it make > sense to define a > field to encode a group assignment? For instance, the Netconf server may > not know who > "kwatsen" is, but it sees that a CA the NetConf server trusts has stated > that "kwatsen" > is a member of the "admin" group... > > We can include user-specific privilege and access control information in a user's certificate. I don't have access to the X500 specs to extract the exactly name of the field containing such information. Have you the firld name? Thanks > > PS: I find the NetConf Manager/Agent terminology in 5539 confusing - would > it be easier to > always spell out TLS Client/Server and NetConf client/server? > > OK, will replace them > Thanks, > Kent > > > Best regards Badra > > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Badra > Sent: Tuesday, May 24, 2011 9:47 AM > To: netconf@ietf.org > Subject: [Netconf] Updating NETCONF over TLS document (RFC5539) > > Dear all, > > NETCONF over TLS document (RFC5539) update needs to support and fulfill > (additional to the introduction of the Chunked Framing) the requirements > on the username handling defined in 4741bis. > > For the Chunked Framing, I will bring the same way being proposed by > NETCONF over SSH document. Since the only authentication mechanism being > defined by RFC5539 is based on certificates, so I would propose the > following (it borrows text from rfc5216): > > > In NETCONF over TLS, the username is determined from the subject or > subjectAltName fields in the manager's certificates. For details, see > Section 4.1.2.6 of [RFC5280]. > > Where the subjectAltName field is present in the certificate, the username > MUST be set to the contents of the subjectAltName. If subject naming > information is present only in the subjectAltName extension of certificate, > then the subject field MUST be an empty sequence and the subjectAltName > extension MUST be critical. > > Where the username represents a host, a subjectAltName of type dnsName > SHOULD be present in the manager certificate. Where the username > represents > > a user and not a resource, a subjectAltName of type rfc822Name SHOULD be > used. > If a dnsName or rfc822Name are not available, other field types (for > example, > a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be > used. > > Where it is non-empty, the subject name field MUST contain an X.500 > distinguished name (DN). If subject naming information is present only in > the subject name field of the manager's certificate and the username > represents a host or device, the subject name field SHOULD contain a > CommonName (CN) RDN or serialNumber RDN. If subject naming information is > present only in the subject name field of the manager's certificate, then > the subject name field SHOULD contain a CN RDN or serialNumber RDN. > > It is possible for more than one subjectAltName field to be present in the > manager's certificate in addition to an empty or non-empty subject > distinguished name. Implementations of this document SHOULD export all the > subjectAltName fields and the non-empty subject distinguished name field. > All of the exported fields are considered valid. > > The username provided by the implementation of this document will be made > available to the NETCONF message layer as the NETCONF username without > modification. If the username does not comply to the NETCONF requirements > on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not > representable in XML, the TLS session MUST be dropped. Any transformations > applied to the authenticated identity of the TLS client made by the TLS > server (e.g., via authentication services or mappings to system accounts) > are outside the scope of this document. > > Comments? > > Best regards > Badra > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0016e647640a711f1804a40c294d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kent,

On Tue, May 24, 2011 at 7:24 PM, Kent Watsen <kwatsen@juniper.n= et> wrote:
Placing X.500 into the client= 9;s certificate is interesting, but raises the following questions:


1. Since devices are unlikely to know how to map any field other than C= N=3D<username>, should
=A0 the draft explicit state that the other= fields (C, O, OU, etc.) will be ignored?

2. Should the draft say th= at the CN should be a uid (i.e. kwatsen) instead of a full name
=A0 (i.e. Kent Watsen)?

=A0
It should do, What about adding after the
=A0
" Where it is non-empty, the subject name field MUST contain an X= .500
..........=A0contain a CN RDN or serialNumber RDN.
=A0
Implementations of this specification MUST be prepared to ignore
the following standard attribute types in issuer and subject=A0names:<= br>
=A0=A0=A0=A0=A0 * country,
=A0=A0=A0=A0=A0 * organization,
=A0= =A0=A0=A0=A0 * organizational unit,
=A0=A0=A0=A0=A0 * distinguished name= qualifier,
=A0=A0=A0=A0=A0 * state or province name,
=A0=A0=A0=A0=A0 * serial number.
The common name SHOULD be a uid (e.g., "kwatsen"), insteqd o= f full name (e.g. "Kent Wasten").
=A0

3. How would the TLS server auth= enticate the TLS client's certificate? =A0Will the certificate
=A0 b= e signed by a CA the TLS server is previously configured to trust?

=A0
This is beyond TLS, isn't? It is based on PK= I as you described.
=A0
=A0
4. If the TLS client's certi= ficate can be signed by a CA, would it make sense to define a
=A0 field = to encode a group assignment? =A0For instance, the Netconf server may not k= now who
=A0 "kwatsen" is, but it sees that a CA the NetConf server trusts= has stated that "kwatsen"
=A0 is a member of the "admin&= quot; group...

=A0
=A0
We can include user-specific privilege and access control information = in a user's certificate. I don't have access to the X500 specs to e= xtract the exactly name of the field containing such information. Have you = the firld name? Thanks
=A0
=A0

PS: I find the NetConf Manag= er/Agent terminology in 5539 confusing - would it be easier to
=A0 =A0al= ways spell out TLS Client/Server and NetConf client/server?

=A0
OK, will replace them
=A0
Thanks,
Kent


=A0
=A0
Best regards
Badra
=A0



-----Original Message-----
From: netconf-bounces@ietf.org [mailto:<= a href=3D"mailto:netconf-bounces@ietf.org">netconf-bounces@ietf.org] On= Behalf Of Badra
Sent: Tuesday, May 24, 2011 9:47 AM
To: netconf@ietf.org
Subject: [Netconf] Updating NETCONF over TLS do= cument (RFC5539)

Dear all,

NETCONF over TLS document (RFC5539= ) update needs to support and fulfill
(additional to the introduction of the Chunked Framing) the requirementson the username handling defined in 4741bis.

For the Chunked Framin= g, I will bring the same way being proposed by
NETCONF over SSH document= . Since the only authentication mechanism being
defined by RFC5539 is based on certificates, so I would propose the
foll= owing (it borrows text from rfc5216):


In NETCONF over TLS, the u= sername is determined from the subject or
subjectAltName fields in the m= anager's certificates. For details, see
Section 4.1.2.6 of [RFC5280].

Where the subjectAltName field is pres= ent in the certificate, the username
MUST be set to the contents of the = subjectAltName. If subject naming
information is present only in the sub= jectAltName extension of certificate,
then the subject field MUST be an empty sequence and the subjectAltName
= extension MUST be critical.

Where the username represents a host, a = subjectAltName of type dnsName
SHOULD be present in the manager certific= ate. =A0Where the username represents

a user and not a resource, a subjectAltName of type rfc822Name SHOULD b= e
used.
If a dnsName or rfc822Name are not available, other field typ= es (for
example,
a subjectAltName of type ipAddress or uniformResourc= eIdentifier) MAY be
used.

Where it is non-empty, the subject name field MUST contain an = X.500
distinguished name (DN). =A0If subject naming information is prese= nt only in
the subject name field of the manager's certificate and t= he username
represents a host or device, the subject name field SHOULD contain a
Com= monName (CN) RDN or serialNumber RDN. =A0If subject naming information ispresent only in the subject name field of the manager's certificate, = then
the subject name field SHOULD contain a CN RDN or serialNumber RDN.

= It is possible for more than one subjectAltName field to be present in the<= br>manager's certificate in addition to an empty or non-empty subject distinguished name. =A0Implementations of this document SHOULD export all t= he
subjectAltName fields and the non-empty subject distinguished name fi= eld.
All of the exported fields are considered valid.

The usernam= e provided by the implementation of this document will be made
available to the NETCONF message layer as the NETCONF username without
m= odification. =A0If the username does not comply to the NETCONF requirements=
on usernames [I-D.ietf-netconf-4741bis] , i.e., the username is not
representable in XML, the TLS session MUST be dropped. =A0Any transformatio= ns
applied to the authenticated identity of the TLS client made by the T= LS
server (e.g., via authentication services or mappings to system accou= nts)
are outside the scope of this document.

Comments?

Best regard= s
Badra
_______________________________________________Netconf mailing list
Netconf@ietf.= org
https://www.ietf.org/mailman/listinfo/netconf

--0016e647640a711f1804a40c294d-- From kwatsen@juniper.net Tue May 24 15:02:57 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A8E07A8 for ; Tue, 24 May 2011 15:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPwN1GMx7fpT for ; Tue, 24 May 2011 15:02:56 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84CE07A7 for ; Tue, 24 May 2011 15:02:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwrDdDgtsuTQEZzqflUcE+qxjS6Qm6K@postini.com; Tue, 24 May 2011 15:02:56 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 24 May 2011 15:02:12 -0700 From: Kent Watsen To: "Bert (IETF) Wijnen" , netconf Date: Tue, 24 May 2011 15:02:09 -0700 Thread-Topic: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question Thread-Index: AcwWDbxllJzTpzUlQKS2aZLvyM6R6gER2x5w Message-ID: <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> References: <4DD4EDCD.6030406@bwijnen.net> In-Reply-To: <4DD4EDCD.6030406@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:02:57 -0000 The reason I don't have an opinion about the proposal presented in the slid= es is because I have a larger issue with the I-D as a whole: 1. It's unclear why this problem needs to be solved. The I-D says: "The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment, which promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF operations and content." And: "There is a need for inter-operable management of the controlled access to operator selected portions of the available NETCONF content within a particular server." But I don't understand it - but this might be due to my view that=20 NetConf is primarily for NMSs (see my #3). 2. It seems unlikely device vendors will implement it. This YANG module can be optionally advertized. What motivation do=20 device vendors have to implement it? - especially as it may conflict with their native RBAC model or interoperability with external authorization servers. 3. It seems unnecessary to support NMS applications. I can't speak for all, but our NMS expects to configured to log into devices with a root-like account. Customers configuring a centralized management system want the NMS to "own" the box and then provide its own RBAC abstraction via its UI. An NACM solution wouldn't have much impact on our NMS. Furthermore, the user account the NMS logs into=20 the device with is typically the only one on the device that is ever used, so an NACM solution would again not have much use. Sorry to hold my thoughts for so long, but I wasn't sure how the I-D was go= ing to shape up. Now that I see where it's going, I find I have some reser= vations for it... Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert (IETF) Wijnen Sent: Thursday, May 19, 2011 6:16 AM To: netconf Subject: [Netconf] Action from WG participants PLEASE: Access Control Issue= s/Question Sofar, it seems no-one has rected to the below. Please, please, we can hardly imagine no-one has any opinions on these topics. We are a WG, that means we need to discuss and try to come to consensus on these matters. Bert and Mehmet -------- Original Message -------- Subject: [Netconf] Access Control Issues/Question Date: Fri, 01 Apr 2011 10:49:34 +0200 From: Bert Wijnen To: Netconf WG participants, Pls comment on this open issues that Martin presented in his suggested new/improved approach for NACM rule definitions at our meeting yesterday. The slides are here: http://tools.ietf.org/agenda/80/slides/netconf-1.pdf - Is two levels of nesting enough? - A common (?) use case is to define one rulelist for a task, and let some groups access it read-write, and some read-only. This is not directly supported - you would need to define two different rule-lists, e.g. routing- admin and routing-read. By moving the allowedgroups check from the rule to the rulelist, we loose some flexibility. If we really need special handling of a rule for some group, this rule needs to be defined in a separate rule-list. - Would it be useful with any objects to help debug a NACM configuration? - rpc get-rules group-name ---> list of rules - rpc check-path group-name path ---> rule execution trace Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From ietf@andybierman.com Tue May 24 15:25:33 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B21E07F2 for ; Tue, 24 May 2011 15:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlI0YgyqlHmp for ; Tue, 24 May 2011 15:25:33 -0700 (PDT) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF18E07EC for ; Tue, 24 May 2011 15:25:32 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p4OMPWXt028418 for ; Tue, 24 May 2011 18:25:32 -0400 Authentication-Results: cm-omr6 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:59234] helo=[192.168.0.22]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 03/37-03149-B503CDD4; Tue, 24 May 2011 18:25:32 -0400 Message-ID: <4DDC3024.2040400@andybierman.com> Date: Tue, 24 May 2011 15:24:36 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <4DD4EDCD.6030406@bwijnen.net> <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:25:34 -0000 On 05/24/2011 03:02 PM, Kent Watsen wrote: > > The reason I don't have an opinion about the proposal presented in the slides is because I have a larger issue with the I-D as a whole: > > > 1. It's unclear why this problem needs to be solved. > > The I-D says: > > "The standardization of network configuration interfaces for use with > the NETCONF protocol requires a structured and secure operating > environment, which promotes human usability and multi-vendor > interoperability. There is a need for standard mechanisms to > restrict NETCONF protocol access for particular users to a pre- > configured subset of all available NETCONF operations and content." > > And: > > "There is a need for inter-operable management of the controlled > access to operator selected portions of the available NETCONF content > within a particular server." > > But I don't understand it - but this might be due to my view that > NetConf is primarily for NMSs (see my #3). > What if there are multiple NMS applications, and the database subtrees they need do not really overlap? What if the people using these apps need to login to them, so there really can be different classes of users. There may be a mix of operators (on lo-touch objects) and applications (on hi-touch objects) so assuming a framework with just 1 NMS and no operator applications using NETCONF is not 100% realistic. Assuming all users can have all access to all operations and all data is not a good solution. Assuming a vendor-specific RBAC implementation will deal with it just proves there is a need for a standard solution. > > 2. It seems unlikely device vendors will implement it. > > This YANG module can be optionally advertized. What motivation do > device vendors have to implement it? - especially as it may conflict > with their native RBAC model or interoperability with external > authorization servers. > > We are working with our NETCONF stack vendor to get this implemented in products. What motivation does a vendor have to implement any standard, except that they want to converge on a single solution. > 3. It seems unnecessary to support NMS applications. > > I can't speak for all, but our NMS expects to configured to log into > devices with a root-like account. Customers configuring a centralized > management system want the NMS to "own" the box and then provide its > own RBAC abstraction via its UI. An NACM solution wouldn't have much > impact on our NMS. Furthermore, the user account the NMS logs into > the device with is typically the only one on the device that is ever > used, so an NACM solution would again not have much use. > > Assuming root access for all NETCONF write activity is not good enough for the standard. Using just 1 role for 'edit' vs. multiple roles is a site-specific decision. The standard should support the ability to restrict a role to specific operations and specific data. > Sorry to hold my thoughts for so long, but I wasn't sure how the I-D was going to shape up. Now that I see where it's going, I find I have some reservations for it... > > Thanks, > Kent Andy From kwatsen@juniper.net Tue May 24 15:41:07 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98AE07A8 for ; Tue, 24 May 2011 15:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9PVhmjskRGR for ; Tue, 24 May 2011 15:41:06 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 01C93E06AC for ; Tue, 24 May 2011 15:41:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTdwz/qIeBVdFCwR38go6z6U2FRabm58Q@postini.com; Tue, 24 May 2011 15:41:06 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 24 May 2011 15:40:42 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 24 May 2011 15:40:40 -0700 Thread-Topic: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question Thread-Index: AcwaYX/hP07TMHEFSQCfCpR+AKDPhQAAGvHg Message-ID: <84600D05C20FF943918238042D7670FD3E7F361DFB@EMBX01-HQ.jnpr.net> References: <4DD4EDCD.6030406@bwijnen.net> <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> <4DDC3024.2040400@andybierman.com> In-Reply-To: <4DDC3024.2040400@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:41:07 -0000 > assuming a framework with just 1 NMS and no operator > applications using NETCONF is not 100% realistic. This is just my experience. Of course, our customers usually leave open CLI/WebUI access but, presumably, the access-control for those interfaces is not impacted by NACM (right?) > Assuming a vendor-specific RBAC implementation will deal with it just > proves there is a need for a standard solution. What I would like to see is a standard RBAC/ACM abstraction that would=20 apply to all interfaces. That is, vendors would read/write the IETF namespaced ACM data-model to/from their internal data-model, such that it affects all user interfaces. This is the pattern that I wrote about here: http://www.ietf.org/mail-archive/web/netconf/current/msg06925.html Thanks, Kent From ietf@andybierman.com Tue May 24 16:17:33 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22034E06C9 for ; Tue, 24 May 2011 16:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B70e3Yi7F32 for ; Tue, 24 May 2011 16:17:32 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 154C4E0695 for ; Tue, 24 May 2011 16:17:32 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p4ONHVZF019276 for ; Tue, 24 May 2011 19:17:31 -0400 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43360] helo=[192.168.0.22]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 50/FB-31934-A8C3CDD4; Tue, 24 May 2011 19:17:31 -0400 Message-ID: <4DDC3C52.5040008@andybierman.com> Date: Tue, 24 May 2011 16:16:34 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <4DD4EDCD.6030406@bwijnen.net> <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> <4DDC3024.2040400@andybierman.com> <84600D05C20FF943918238042D7670FD3E7F361DFB@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F361DFB@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 23:17:33 -0000 On 05/24/2011 03:40 PM, Kent Watsen wrote: >> assuming a framework with just 1 NMS and no operator >> applications using NETCONF is not 100% realistic. > > This is just my experience. Of course, our customers usually leave open > CLI/WebUI access but, presumably, the access-control for those interfaces > is not impacted by NACM (right?) not officially. > > >> Assuming a vendor-specific RBAC implementation will deal with it just >> proves there is a need for a standard solution. > > What I would like to see is a standard RBAC/ACM abstraction that would > apply to all interfaces. That is, vendors would read/write the IETF > namespaced ACM data-model to/from their internal data-model, such that > it affects all user interfaces. This is the pattern that I wrote about > here: > > http://www.ietf.org/mail-archive/web/netconf/current/msg06925.html > This is a message on the system notifications draft... It is too difficult to write adequate standards that apply to unspecified proprietary CLI or other UI interfaces. We will map the same data model ACM rules for CLI and NETCONF access for the portions of our implementation where the NETCONF and CLI data models are basically the same. But it is outside the scope of the NETCONF WG charter how this is done. > > Thanks, > Kent > > > Andy From j.schoenwaelder@jacobs-university.de Tue May 24 16:52:58 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E18E0761 for ; Tue, 24 May 2011 16:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G4pmX50Sfw9 for ; Tue, 24 May 2011 16:52:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 041DDE075F for ; Tue, 24 May 2011 16:52:57 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9324C20CB0; Wed, 25 May 2011 01:52:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qXi1pDN84HaN; Wed, 25 May 2011 01:52:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E610E20C73; Wed, 25 May 2011 01:52:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF89B18B5F1C; Wed, 25 May 2011 01:52:54 +0200 (CEST) Date: Wed, 25 May 2011 01:52:54 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110524235254.GA2023@elstar.local> Mail-Followup-To: Kent Watsen , Ladislav Lhotka , "netconf@ietf.org" References: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 23:52:58 -0000 On Tue, May 24, 2011 at 01:46:42PM -0700, Kent Watsen wrote: > > Oh, but let's not forget these two 4741bisbis issues (http://www.ietf.org/mail-archive/web/netconf/current/msg06734.html) ;) > > Actually, I posted a "solution" for the second issue (http://www.ietf.org/mail-archive/web/netconf/current/msg06744.html), though it's not very nice for either clients or servers... 4741bis is in the RFC editor queue - this is not a good time to request any substantial changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue May 24 17:11:58 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B7E073C for ; Tue, 24 May 2011 17:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTkv+TOfaZad for ; Tue, 24 May 2011 17:11:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 49A66E064E for ; Tue, 24 May 2011 17:11:57 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1CAE20CB1; Wed, 25 May 2011 02:11:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HHcjZKB8Z90S; Wed, 25 May 2011 02:11:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC17E20CA8; Wed, 25 May 2011 02:11:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC6BB18B614E; Wed, 25 May 2011 02:11:55 +0200 (CEST) Date: Wed, 25 May 2011 02:11:55 +0200 From: Juergen Schoenwaelder To: Badra Message-ID: <20110525001155.GA2121@elstar.local> Mail-Followup-To: Badra , Kent Watsen , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 00:11:58 -0000 On Tue, May 24, 2011 at 11:20:48PM +0200, Badra wrote: > The common name SHOULD be a uid (e.g., "kwatsen"), insteqd of full name > (e.g. "Kent Wasten"). What is the definition of a uid? In UNIX, a uid is a number... And why does this matter at all? If I choose to call someone "Ken Watsen" then this should be just fine, no? What is going to break in NETCONF if Ken is called "Ken Watsen"? > > 3. How would the TLS server authenticate the TLS client's certificate? Will > > the certificate > > be signed by a CA the TLS server is previously configured to trust? > > > This is beyond TLS, isn't? It is based on PKI as you described. I do not think this is beyond TLS. I assume a server needs to verify the presented certificate - are you saying that is not the case?? RFC 5539 says: The server MUST verify the identity of the client with certificate- based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. So what does this text mean in implementation terms? Since a server does not have a human in the loop to take decisions, how does a server "verify the identity of the client with certificate-based authentication according to local policy" if there is not some form or a PKI? I think it is important to be explicit what this text means - and in particular it should _not_ be sufficient to accept certificates just because they contain certain values in some convenient places. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Tue May 24 17:16:05 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0D6E073C for ; Tue, 24 May 2011 17:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdB8EvmLfXFw for ; Tue, 24 May 2011 17:16:04 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC9E064E for ; Tue, 24 May 2011 17:16:01 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p4P0G1th012122 for ; Tue, 24 May 2011 20:16:01 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:41703] helo=[192.168.0.22]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BE/47-05097-04A4CDD4; Tue, 24 May 2011 20:16:01 -0400 Message-ID: <4DDC4A08.7050806@andybierman.com> Date: Tue, 24 May 2011 17:15:04 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen , Ladislav Lhotka , "netconf@ietf.org" References: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> <20110524235254.GA2023@elstar.local> In-Reply-To: <20110524235254.GA2023@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 00:16:05 -0000 On 05/24/2011 04:52 PM, Juergen Schoenwaelder wrote: > On Tue, May 24, 2011 at 01:46:42PM -0700, Kent Watsen wrote: >> >> Oh, but let's not forget these two 4741bisbis issues (http://www.ietf.org/mail-archive/web/netconf/current/msg06734.html) ;) >> >> Actually, I posted a "solution" for the second issue (http://www.ietf.org/mail-archive/web/netconf/current/msg06744.html), though it's not very nice for either clients or servers... > > 4741bis is in the RFC editor queue - this is not a good time to > request any substantial changes. > I strongly object to any changes to the 4741bis draft. Leave it in the RFC editor queue. Do not pull it back for more WG input and more IESG review. > /js > Andy From phil@juniper.net Tue May 24 20:08:07 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788DE078C for ; Tue, 24 May 2011 20:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIb4PMy7wu+F for ; Tue, 24 May 2011 20:08:06 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id D5920E06E3 for ; Tue, 24 May 2011 20:07:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTdxyjCGwqHM/gBIu2kbdkqiQ4ayUh4r9@postini.com; Tue, 24 May 2011 20:08:06 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 24 May 2011 20:06:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p4P36Pv11851; Tue, 24 May 2011 20:06:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p4P2fteo071670; Wed, 25 May 2011 02:41:57 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201105250241.p4P2fteo071670@idle.juniper.net> To: Andy Bierman In-Reply-To: <4DDC3024.2040400@andybierman.com> Date: Tue, 24 May 2011 22:41:55 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:08:07 -0000 Andy Bierman writes: >Assuming all users can have all access to all operations and all data >is not a good solution. Assuming a vendor-specific RBAC implementation >will deal with it just proves there is a need for a standard solution. My assumption is that the admin that configured the application's user permissions will give it sufficient to perform whatever actions are needed/desired, and the number of admins using netconf to provision that initial access will be extremely low. Thanks, Phil From kwatsen@juniper.net Tue May 24 20:08:44 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74410E0751 for ; Tue, 24 May 2011 20:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWQmm30M8GVy for ; Tue, 24 May 2011 20:08:44 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id B0448E06E3 for ; Tue, 24 May 2011 20:08:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTdxyuQQr4cPa1oBYU+k+2ffYMtD1daAs@postini.com; Tue, 24 May 2011 20:08:43 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 24 May 2011 20:06:24 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 24 May 2011 20:06:20 -0700 Thread-Topic: [Netconf] namespace of "operation" attribute Thread-Index: AcwaiLqza/Qw66P7RC6xunT4PWQLkA== Message-ID: <03F2894E-E135-4CD4-A105-BC67B8DE550E@juniper.net> References: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> <20110524235254.GA2023@elstar.local> <4DDC4A08.7050806@andybierman.com> In-Reply-To: <4DDC4A08.7050806@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:08:44 -0000 I agree that it's too late for 4741bis, which is why I wrote 4741bisbis, th= at is, the "bis" after 4741bis. =20 I only added this comment to ensure the other "missed" issues would stay fr= esh Thanks, Kent On May 24, 2011, at 8:16 PM, "Andy Bierman" wrote: > On 05/24/2011 04:52 PM, Juergen Schoenwaelder wrote: >> On Tue, May 24, 2011 at 01:46:42PM -0700, Kent Watsen wrote: >>>=20 >>> Oh, but let's not forget these two 4741bisbis issues (http://www.ietf.o= rg/mail-archive/web/netconf/current/msg06734.html) ;) >>>=20 >>> Actually, I posted a "solution" for the second issue (http://www.ietf.o= rg/mail-archive/web/netconf/current/msg06744.html), though it's not very ni= ce for either clients or servers... >>=20 >> 4741bis is in the RFC editor queue - this is not a good time to >> request any substantial changes. >>=20 >=20 > I strongly object to any changes to the 4741bis draft. > Leave it in the RFC editor queue. Do not pull it back > for more WG input and more IESG review. >=20 >> /js >>=20 >=20 > Andy From kwatsen@juniper.net Tue May 24 20:30:20 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6587E078C for ; Tue, 24 May 2011 20:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5GazdkXxGlO for ; Tue, 24 May 2011 20:30:20 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 15942E06F3 for ; Tue, 24 May 2011 20:30:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTdx3yGxeU/vB6f+JHxN9wsJJgNQSCfuu@postini.com; Tue, 24 May 2011 20:30:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 24 May 2011 20:23:29 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 24 May 2011 20:23:24 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acwaix1/jrGTNj+JSPq4ovjaZKQrjg== Message-ID: <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> In-Reply-To: <20110525001155.GA2121@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:30:20 -0000 DQpXaGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGEgdWlkPyBJbiBVTklYLCBhIHVpZCBpcyBhIG51 bWJlci4uLiBBbmQgd2h5DQpkb2VzIHRoaXMgbWF0dGVyIGF0IGFsbD8gSWYgSSBjaG9vc2UgdG8g Y2FsbCBzb21lb25lICJLZW4gV2F0c2VuIiB0aGVuDQp0aGlzIHNob3VsZCBiZSBqdXN0IGZpbmUs IG5vPyBXaGF0IGlzIGdvaW5nIHRvIGJyZWFrIGluIE5FVENPTkYgaWYgS2VuDQppcyBjYWxsZWQg IktlbiBXYXRzZW4iPw0KDQpJdCBkb2Vzbid0IGhhdmUgdG8gYmUgInVpZCIgaW4gYSBVTklYIHNl bnNlLCBidXQgSSB0aGluayB0aGF0IHRoZSBjb21tb24gbmFtZSBNVVNUIG1hcCB0byBhIHVzZXIg YWNjb3VudCB0aGUgZGV2aWNlIGNhbiBtYXAgdG8gYW4gQUNMLg0KDQoNCkkgZG8gbm90IHRoaW5r IHRoaXMgaXMgYmV5b25kIFRMUy4gSSBhc3N1bWUgYSBzZXJ2ZXIgbmVlZHMgdG8gdmVyaWZ5IHRo ZQ0KcHJlc2VudGVkIGNlcnRpZmljYXRlIC0gYXJlIHlvdSBzYXlpbmcgdGhhdCBpcyBub3QgdGhl IGNhc2U/PyBSRkMgNTUzOQ0Kc2F5czoNCg0KICBUaGUgc2VydmVyIE1VU1QgdmVyaWZ5IHRoZSBp ZGVudGl0eSBvZiB0aGUgY2xpZW50IHdpdGggY2VydGlmaWNhdGUtDQogIGJhc2VkIGF1dGhlbnRp Y2F0aW9uIGFjY29yZGluZyB0byBsb2NhbCBwb2xpY3kgdG8gZW5zdXJlIHRoYXQgdGhlDQogIGlu Y29taW5nIGNsaWVudCByZXF1ZXN0IGlzIGxlZ2l0aW1hdGUgYmVmb3JlIGFueSBjb25maWd1cmF0 aW9uIG9yDQogIHN0YXRlIGRhdGEgaXMgc2VudCB0byBvciByZWNlaXZlZCBmcm9tIHRoZSBjbGll bnQuDQoNClNvIHdoYXQgZG9lcyB0aGlzIHRleHQgbWVhbiBpbiBpbXBsZW1lbnRhdGlvbiB0ZXJt cz8gU2luY2UgYSBzZXJ2ZXINCmRvZXMgbm90IGhhdmUgYSBodW1hbiBpbiB0aGUgbG9vcCB0byB0 YWtlIGRlY2lzaW9ucywgaG93IGRvZXMgYSBzZXJ2ZXINCiJ2ZXJpZnkgdGhlIGlkZW50aXR5IG9m IHRoZSBjbGllbnQgd2l0aCBjZXJ0aWZpY2F0ZS1iYXNlZA0KYXV0aGVudGljYXRpb24gYWNjb3Jk aW5nIHRvIGxvY2FsIHBvbGljeSIgaWYgdGhlcmUgaXMgbm90IHNvbWUgZm9ybSBvcg0KYSBQS0k/ IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGJlIGV4cGxpY2l0IHdoYXQgdGhpcyB0ZXh0IG1l YW5zIC0NCmFuZCBpbiBwYXJ0aWN1bGFyIGl0IHNob3VsZCBfbm90XyBiZSBzdWZmaWNpZW50IHRv IGFjY2VwdCBjZXJ0aWZpY2F0ZXMNCmp1c3QgYmVjYXVzZSB0aGV5IGNvbnRhaW4gY2VydGFpbiB2 YWx1ZXMgaW4gc29tZSBjb252ZW5pZW50IHBsYWNlcy4NCg0KRXhhY3RseS4gICBUaGUgb25seSB3 YXkgdGhpcyBSRkMgbWFrZXMgc2Vuc2UgaXMgaWYgdGhlIGRldmljZSBjYW4gdmFsaWRhdGUgdGhl IHByZXN1bWVkIHVzZXIncyBpZGVudGl0eS4gIEFzIGl0IGlzIHdyaXR0ZW4gbm93LCBhbnkgbWFs aWNpb3VzIGFnZW50IGNvdWxkIGxvZyBpbnRvIGEgZGV2aWNlLg0K From lhotka@cesnet.cz Tue May 24 23:18:03 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA437E067B for ; Tue, 24 May 2011 23:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xjd5V77y+S3 for ; Tue, 24 May 2011 23:18:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 56602E065B for ; Tue, 24 May 2011 23:18:00 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9D6D32CDE057; Wed, 25 May 2011 08:17:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--567919852; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4DDC4A08.7050806@andybierman.com> Date: Wed, 25 May 2011 08:17:58 +0200 Message-Id: <821889C7-60BA-4F12-9889-0A7CB8355C2D@cesnet.cz> References: <5AEAEA5C-ADAE-43AE-AF75-58D0D097F618@cesnet.cz> <84600D05C20FF943918238042D7670FD3E7F361BE4@EMBX01-HQ.jnpr.net> <20110524235254.GA2023@elstar.local> <4DDC4A08.7050806@andybierman.com> To: Andy Bierman X-Mailer: Apple Mail (2.1084) Cc: "netconf@ietf.org" Subject: Re: [Netconf] namespace of "operation" attribute X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 06:18:03 -0000 --Apple-Mail-1--567919852 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 25, 2011, at 2:15 AM, Andy Bierman wrote: > On 05/24/2011 04:52 PM, Juergen Schoenwaelder wrote: >> On Tue, May 24, 2011 at 01:46:42PM -0700, Kent Watsen wrote: >>>=20 >>> Oh, but let's not forget these two 4741bisbis issues = (http://www.ietf.org/mail-archive/web/netconf/current/msg06734.html) ;) >>>=20 >>> Actually, I posted a "solution" for the second issue = (http://www.ietf.org/mail-archive/web/netconf/current/msg06744.html), = though it's not very nice for either clients or servers... >>=20 >> 4741bis is in the RFC editor queue - this is not a good time to >> request any substantial changes. >>=20 >=20 > I strongly object to any changes to the 4741bis draft. > Leave it in the RFC editor queue. Do not pull it back > for more WG input and more IESG review. It was not my intention, but the authors will get a chance to make minor = fixes just before the RFC gets published, right? My proposal regarding = the namespace of the "operation" attribute means no substantial change, = just adding missing information to the text. Cf. the formulation for the = "insert" attribute in the second paragraph of Sec. 7.7.7 of RFC 6020. On the other hand, XSD in App. B is correct in this respect, so the = omission in the text is not critical. Lada =20 =20 Lada >=20 >> /js >>=20 >=20 > Andy -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-1--567919852 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTI1MDYxNzU4WjAjBgkqhkiG9w0BCQQxFgQUrLp3wPPRH0nPYo1LGX0MUJyduo4wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQB3+OT+GWlNOl53SWmAarcE4vua gYoD4liQWwLYQf/nFpcH/xL+35sBRwf9l6XbraLypCm9Q2RnGGlzlVzFGntRj03mFP/5XCYdleVq m+nwIxWyXcyRzxCBqsv9Z8qslh3aFs38JOPIzPmq6X+K2vNHfvHKMWNovsN21xpzfLXuCpeRl2rD 05rnWWpWMa5HYgUbOVDms4FtgSGmQUhirGdKqF/ALCkUS9SYMqkSKtV7qvDlLM2k0OASTtGCT/e6 FkpUAvskXXzgdA9YGpMh8j/oE6kz7aQMhNLxBrFI+RmNfn0dH5r5dW+AGNlVn0spxALjQ0LDjNGN NvHpcCgmIu/YAAAAAAAA --Apple-Mail-1--567919852-- From biermana@Brocade.com Wed May 25 09:38:17 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF0EE0756 for ; Wed, 25 May 2011 09:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8Wv2bGLX7zI for ; Wed, 25 May 2011 09:38:16 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id A8D8DE074E for ; Wed, 25 May 2011 09:38:16 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p4PGbCqA004875; Wed, 25 May 2011 09:38:15 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0a-000f0801.pphosted.com with ESMTP id wh4k70150-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 May 2011 09:38:15 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 25 May 2011 09:42:11 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 25 May 2011 09:38:13 -0700 From: Andy Bierman To: Phil Shafer , Andy Bierman Date: Wed, 25 May 2011 09:38:12 -0700 Thread-Topic: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question Thread-Index: AcwaiWk4/BowhKuAS8CN0JbrTxGvyQAcA28A Message-ID: References: <4DDC3024.2040400@andybierman.com> <201105250241.p4P2fteo071670@idle.juniper.net> In-Reply-To: <201105250241.p4P2fteo071670@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-05-25_07:2011-05-25, 2011-05-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1105250098 Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:38:17 -0000 Whether the admin uses a proprietary data model or a standard data model to configure the application's permissions is a business/technical decision each vendor can make for themselves. How often access control is configured is relative to the applications in use. You have made it clear that you do not see any need to have a standard access model and you are happy continuing to use your own data model. At this point the charter discussions are over for NACM. If other people think we should rewrite the charter or throw out the work item, they should speak up sooner rather than later. Andy -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Phil Shafer Sent: Tuesday, May 24, 2011 7:42 PM To: Andy Bierman Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control I= ssues/Question Andy Bierman writes: >Assuming all users can have all access to all operations and all data >is not a good solution. Assuming a vendor-specific RBAC implementation >will deal with it just proves there is a need for a standard solution. My assumption is that the admin that configured the application's user permissions will give it sufficient to perform whatever actions are needed/desired, and the number of admins using netconf to provision that initial access will be extremely low. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Wed May 25 09:40:32 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEA2E081D for ; Wed, 25 May 2011 09:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc-bnhgQqlF8 for ; Wed, 25 May 2011 09:40:32 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id E1A87E0756 for ; Wed, 25 May 2011 09:40:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTd0w/ea4zqgySVcv6n38xa1DK6VBNhUn@postini.com; Wed, 25 May 2011 09:40:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 25 May 2011 09:38:12 -0700 From: Kent Watsen To: Kent Watsen , Juergen Schoenwaelder Date: Wed, 25 May 2011 09:38:10 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acwaix1/jrGTNj+JSPq4ovjaZKQrjgAblZcA Message-ID: <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> In-Reply-To: <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:40:32 -0000 [I sent this response originally from my phone, which didn't quote Juergon'= s comments correctly - which is fixed below] > What is the definition of a uid? In UNIX, a uid is a number... And why > does this matter at all? If I choose to call someone "Ken Watsen" then > this should be just fine, no? What is going to break in NETCONF if Ken > is called "Ken Watsen"? It doesn't have to be "uid" in a UNIX sense, but I think that the common na= me MUST map to a user account the device can map to an ACL. > I do not think this is beyond TLS. I assume a server needs to verify the > presented certificate - are you saying that is not the case?? RFC 5539 > says: > > The server MUST verify the identity of the client with certificate- > based authentication according to local policy to ensure that the > incoming client request is legitimate before any configuration or > state data is sent to or received from the client. > > So what does this text mean in implementation terms? Since a server > does not have a human in the loop to take decisions, how does a server > "verify the identity of the client with certificate-based > authentication according to local policy" if there is not some form or > a PKI? I think it is important to be explicit what this text means - > and in particular it should _not_ be sufficient to accept certificates > just because they contain certain values in some convenient places. Exactly. The only way this RFC makes sense is if the device can validate = the presumed user's identity. As it is written now, any malicious agent co= uld log into a device. From mbadra@gmail.com Wed May 25 10:26:58 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C73E0686 for ; Wed, 25 May 2011 10:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ6uhN3Nbbzx for ; Wed, 25 May 2011 10:26:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1689EE0684 for ; Wed, 25 May 2011 10:26:58 -0700 (PDT) Received: by vws12 with SMTP id 12so7225704vws.31 for ; Wed, 25 May 2011 10:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ylLlsS60fhKq0L3aZXBh64tTk3IyAhMR2RaFxTDymCM=; b=ehKEvIsDwrUo6QzcQZafH6PanJw9E39nd39wV6LjOSYUyacycuzorGviHFnUHI4jZ4 pGRCZ1ZzJtMc60vJGOD0F+rEmF5kl8BB5+mTOXMHpSee/q7DG29ZBdDGxL+++/QwNJgp RvLyxLnWO1tUKwTP9nRo+iOrHV6WDeHm1ZR9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dxtV8L4Uq8ntxoBh325yqvLiGezoyLeutzLHl91sBp4eC9lqJnN/nu0r7/MZhbkLND UqnNVA8AmFJZ0PqQxY4UuCzd18Udi3Xli/7FkHhKE7QROCNMGXfhbojCaVaTKikVsThG MbCEIa00oZy9pzAqgGET/DaTmNxXvOtCDLFDc= MIME-Version: 1.0 Received: by 10.220.71.196 with SMTP id i4mr1662129vcj.134.1306344417522; Wed, 25 May 2011 10:26:57 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Wed, 25 May 2011 10:26:57 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> Date: Wed, 25 May 2011 19:26:57 +0200 Message-ID: From: Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=0016e6460420f5f5bd04a41d024d Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:26:59 -0000 --0016e6460420f5f5bd04a41d024d Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 25, 2011 at 6:38 PM, Kent Watsen wrote: > [I sent this response originally from my phone, which didn't quote > Juergon's comments correctly - which is fixed below] > > > > > What is the definition of a uid? In UNIX, a uid is a number... And why > > does this matter at all? If I choose to call someone "Ken Watsen" then > > this should be just fine, no? What is going to break in NETCONF if Ken > > is called "Ken Watsen"? > > It doesn't have to be "uid" in a UNIX sense, but I think that the common > name MUST map to a user account the device can map to an ACL. > > > > > I do not think this is beyond TLS. I assume a server needs to verify the > > presented certificate - are you saying that is not the case?? RFC 5539 > > says: > > > > The server MUST verify the identity of the client with certificate- > > based authentication according to local policy to ensure that the > > incoming client request is legitimate before any configuration or > > state data is sent to or received from the client. > > > > So what does this text mean in implementation terms? Since a server > > does not have a human in the loop to take decisions, how does a server > > "verify the identity of the client with certificate-based > > authentication according to local policy" if there is not some form or > > a PKI? I think it is important to be explicit what this text means - > > and in particular it should _not_ be sufficient to accept certificates > > just because they contain certain values in some convenient places. > > Exactly. The only way this RFC makes sense is if the device can validate > the presumed user's identity. As it is written now, any malicious agent > could log into a device. > The server should verify the certificate as described in the document and by rfc5246. Access control based on information exported from the certificate are out of scope of TLS. This is what I wanted to say. I don't know how I have to change the text since I didn't get the point of the malicious agent. Please don't hesitate to propose some text to resolve the issue Best regards Badra --0016e6460420f5f5bd04a41d024d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2011 at 6:38 PM, Kent Watsen <kwatsen@juniper.n= et> wrote:
[I sent this response originally= from my phone, which didn't quote Juergon's comments correctly - w= hich is fixed below]



> What is the definition of a uid? In UNIX= , a uid is a number... And why
> does this matter at all? If I choose= to call someone "Ken Watsen" then
> this should be just fi= ne, no? What is going to break in NETCONF if Ken
> is called "Ken Watsen"?

It doesn't have to be &qu= ot;uid" in a UNIX sense, but I think that the common name MUST map to = a user account the device can map to an ACL.



> I do not t= hink this is beyond TLS. I assume a server needs to verify the
> presented certificate - are you saying that is not the case?? RFC 5539=
> says:
>
> =A0The server MUST verify the identity of th= e client with certificate-
> =A0based authentication according to loc= al policy to ensure that the
> =A0incoming client request is legitimate before any configuration or> =A0state data is sent to or received from the client.
>
>= ; So what does this text mean in implementation terms? Since a server
&g= t; does not have a human in the loop to take decisions, how does a server > "verify the identity of the client with certificate-based
>= authentication according to local policy" if there is not some form o= r
> a PKI? I think it is important to be explicit what this text mean= s -
> and in particular it should _not_ be sufficient to accept certificates=
> just because they contain certain values in some convenient places= .

Exactly. =A0 The only way this RFC makes sense is if the device ca= n validate the presumed user's identity. =A0As it is written now, any m= alicious agent could log into a device.
=A0
The server should verify the certificate as described in the document = and by rfc5246. Access control based on information exported from the certi= ficate are out of scope of TLS. This is what I wanted to say.
=A0
I don't know how I have to change the text since I didn't get = the point of the malicious agent. Please don't hesitate to propose some= text to resolve the issue
Best regards
Badra
--0016e6460420f5f5bd04a41d024d-- From kwatsen@juniper.net Wed May 25 11:01:12 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05CAE0808 for ; Wed, 25 May 2011 11:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47r04Ic-g3YN for ; Wed, 25 May 2011 11:01:12 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1AE0806 for ; Wed, 25 May 2011 11:01:11 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTd1D5Kc73JQKfBCZTw5MyBHGV0PWdQ37@postini.com; Wed, 25 May 2011 11:01:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 25 May 2011 10:59:18 -0700 From: Kent Watsen To: Andy Bierman Date: Wed, 25 May 2011 10:59:17 -0700 Thread-Topic: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question Thread-Index: AcwaaMKyDJbj4RpVTsyNXLua+nNmBQAkcYeQ Message-ID: <84600D05C20FF943918238042D7670FD3E7F36245F@EMBX01-HQ.jnpr.net> References: <4DD4EDCD.6030406@bwijnen.net> <84600D05C20FF943918238042D7670FD3E7F361D45@EMBX01-HQ.jnpr.net> <4DDC3024.2040400@andybierman.com> <84600D05C20FF943918238042D7670FD3E7F361DFB@EMBX01-HQ.jnpr.net> <4DDC3C52.5040008@andybierman.com> In-Reply-To: <4DDC3C52.5040008@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: netconf Subject: Re: [Netconf] Action from WG participants PLEASE: Access Control Issues/Question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:01:13 -0000 >> http://www.ietf.org/mail-archive/web/netconf/current/msg06925.html >> > >This is a message on the system notifications draft... It is, but it presents a vision for having number of standard models (i.e. = modules/capabilities) for managing the whole device, not just a view as see= n via NetConf. Note that the list includes "user management", which is muc= h of what the NACM I-D provides... > It is too difficult to write adequate standards that apply to unspecified > proprietary CLI or other UI interfaces. I didn't mean to imply that. I meant that the standard model would reflect= access to the data, regardless which interface is used to access the devic= e.=20 > We will map the same data model ACM rules for CLI and NETCONF access > for the portions of our implementation where the NETCONF and CLI data mod= els > are basically the same. =20 Yes, exactly, this is what I'd hope > But it is outside the scope of the NETCONF WG charter how this is done. I agree that *how* it's done is out of scope, but that it *is* done is what= I want. I want the access-control to apply the device as a whole, not ju= st when accessed via NetConf. PS: Going back to by first post on this, I wrote "It's unclear why this pro= blem needs to be solved". I should take that back. I do want standard mod= els for many device features, including access-control or, with a slightly = increased scope, user-management. From kwatsen@juniper.net Wed May 25 13:01:34 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B2AE0724 for ; Wed, 25 May 2011 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJltb1jBoE6j for ; Wed, 25 May 2011 13:01:34 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id BB460E0684 for ; Wed, 25 May 2011 13:01:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTd1gGd6U5IS6Y/d/9/4agRzKILigifRu@postini.com; Wed, 25 May 2011 13:01:33 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 25 May 2011 13:00:16 -0700 From: Kent Watsen To: Badra Date: Wed, 25 May 2011 13:00:14 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwbAPOpOiUPZ14vQyGRqU7SiYi9NAABm/9Q Message-ID: <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:01:34 -0000 =A0 > Please don't hesitate to propose some text to resolve the issue How about this? OLD: 3.2. Client Identity The server MUST verify the identity of the client with certificate- based authentication according to local policy to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. NEW: 3.2. Client Identity The server MUST verify the identity of the client with using a Client Certificate (RFC 5246, section 7.4.6). The client's certificate MUST encode the NETCONF username as follows: If the client's certificate type is X.509 (RFC 5280), the NETCONF username MUST be obtained from either the "CN" (Common Name) "emailAddress", or "rfc822Name" fields. If the CN field is set, then the NETCONF username is the value of CN field. If either=20 the emailAddress or rfc822Name fields are set, then the NETCONF username is the "local-part" field (RFC 822). If more than one of these fields are set, the NETCONF username from each must be the same. If the client's certificate type is OpenPGP (RFC 6091), the NETCONF username is extracted from "User ID" field that has been flagged as being the "Primary User ID" field (RFC 4880). The NETCONF username is the "local-part" of the "addr-spec" field (RFC 5322). The username provided by the implementation of this document will be made available to the NETCONF message layer as the NETCONF username without modification. If the username does not comply to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis], i.e., the username is not representable in XML, the TLS session MUST be dropped. Any transformations applied to the authenticated identity of the TLS client made by the TLS server (e.g., via=20 authentication services or mappings to system accounts) are=20 outside the scope of this document. The client's certificate SHOULD be signed by a certificate=20 authority having a valid chain of trust to a certificate authority the server trusts. What do you think? Thanks, Kent From mbadra@gmail.com Wed May 25 15:28:52 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1302E07E0 for ; Wed, 25 May 2011 15:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA3VS-QodFzh for ; Wed, 25 May 2011 15:28:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C94ABE0680 for ; Wed, 25 May 2011 15:28:51 -0700 (PDT) Received: by vxg33 with SMTP id 33so123510vxg.31 for ; Wed, 25 May 2011 15:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rrQT29sbvG+EkNMl8K+WL7TrFQZkai8r3xyLyhTypEk=; b=GYremAUaicCyu69fjoPiFBKrA01grH+mAw1mTnasl0wdnB4egIdnXdZwNs2r6XzSC8 ymUq7dwtAhk0UMKeLRUb4+7UKCG56V+9vy+zMwWb/ODE6wmEH97oOqxDOmzNtPitUEhE gAzti4F7zOE+e5VJaxbSbLDQ6TvRsvGWAziS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dsT8nblaFecKXKATYxswecKpbmwLMhruFMJ0yUgfQ5HflmDQ6DogukpPXV2cQ9lcXW H0/n1Uls3frZRxJqSLxe2xUrKkseoezjc8SMN3KMINOIAXhbgFigeD7JGhaA+Lb1KzFg 2fKbObUa4z74DGhdSUNP1M5h8JuqhnQOimGEo= MIME-Version: 1.0 Received: by 10.52.0.130 with SMTP id 2mr166465vde.180.1306362530937; Wed, 25 May 2011 15:28:50 -0700 (PDT) Received: by 10.220.186.72 with HTTP; Wed, 25 May 2011 15:28:50 -0700 (PDT) In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> Date: Thu, 26 May 2011 00:28:50 +0200 Message-ID: From: Badra To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf304346d49abb0a04a4213a46 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:28:52 -0000 --20cf304346d49abb0a04a4213a46 Content-Type: text/plain; charset=ISO-8859-1 Dear Kent Thanks for the text, I have no objection to adopt it Just a small comment on the following: If more than one of these fields are set, the NETCONF username from each must be the same. Does this mean that we have to carefully set all of those fields to the same value (username) during the certificate generation? Isn't required to keep your early point on the CN; "The common name SHOULD be a uid (e.g., "kwatsen"), instead of full name (e.g. "Kent Wasten")." Best regards Badra On Wed, May 25, 2011 at 10:00 PM, Kent Watsen wrote: > > > Please don't hesitate to propose some text to resolve the issue > > How about this? > > > OLD: > > 3.2. Client Identity > > The server MUST verify the identity of the client with certificate- > based authentication according to local policy to ensure that the > incoming client request is legitimate before any configuration or > state data is sent to or received from the client. > > NEW: > > 3.2. Client Identity > > The server MUST verify the identity of the client with using a > Client Certificate (RFC 5246, section 7.4.6). The client's > certificate MUST encode the NETCONF username as follows: > > If the client's certificate type is X.509 (RFC 5280), the NETCONF > username MUST be obtained from either the "CN" (Common Name) > "emailAddress", or "rfc822Name" fields. If the CN field is set, > then the NETCONF username is the value of CN field. If either > the emailAddress or rfc822Name fields are set, then the NETCONF > username is the "local-part" field (RFC 822). If more than one > of these fields are set, the NETCONF username from each must be > the same. > > If the client's certificate type is OpenPGP (RFC 6091), the > NETCONF username is extracted from "User ID" field that has been > flagged as being the "Primary User ID" field (RFC 4880). The > NETCONF username is the "local-part" of the "addr-spec" field > (RFC 5322). > > The username provided by the implementation of this document > will be made available to the NETCONF message layer as the NETCONF > username without modification. If the username does not comply > to the NETCONF requirements on usernames [I-D.ietf-netconf-4741bis], > i.e., the username is not representable in XML, the TLS session > MUST be dropped. Any transformations applied to the authenticated > identity of the TLS client made by the TLS server (e.g., via > authentication services or mappings to system accounts) are > outside the scope of this document. > > The client's certificate SHOULD be signed by a certificate > authority having a valid chain of trust to a certificate > authority the server trusts. > > > What do you think? > > Thanks, > Kent > > > --20cf304346d49abb0a04a4213a46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Kent
=A0
Thanks for the text, I have no objection to adopt it
Just a small comment on the following:

=A0=A0=A0=A0 If more than one
=A0 =A0 =A0of these fields are se= t, the NETCONF username from each must be
=A0 =A0 =A0the same.
Does this mean that we have to carefully set all of those fields to th= e same value (username) during the certificate generation?
=A0
Isn't required to keep your early point on the CN;
=A0
"The common name SHOULD be a uid (e.g., "kwatsen"), ins= tead of full name (e.g. "Kent Wasten")."
=A0
Best regards
Badra
On Wed, May 25, 2011 at 10:00 PM, Kent Watsen <kwatsen@juniper.= net> wrote:
=A0
> Please don't hesitate to propose some tex= t to resolve the issue

How about this?


OLD:

= =A0 3.2. Client Identity

=A0 =A0 =A0The server MUST verify the identity of the= client with certificate-
=A0 =A0 =A0based authentication according to l= ocal policy to ensure that the
=A0 =A0 =A0incoming client request is leg= itimate before any configuration or
=A0 =A0 =A0state data is sent to or received from the client.

= NEW:

=A0 3.2. Client Identity

=A0 =A0 =A0The server MUST veri= fy the identity of the client with using a
=A0 =A0 =A0Client Certificate= (RFC 5246, section 7.4.6). =A0The client's
=A0 =A0 =A0certificate MUST encode the NETCONF username as follows:

= =A0 =A0 =A0If the client's certificate type is X.509 (RFC 5280), the NE= TCONF
=A0 =A0 =A0username MUST be obtained from either the "CN"= ; (Common Name)
=A0 =A0 =A0"emailAddress", or "rfc822Name" fields. =A0I= f the CN field is set,
=A0 =A0 =A0then the NETCONF username is the value= of CN field. =A0If either
=A0 =A0 =A0the emailAddress or rfc822Name fie= lds are set, then the NETCONF
=A0 =A0 =A0username is the "local-part" field (RFC 822). =A0If mo= re than one
=A0 =A0 =A0of these fields are set, the NETCONF username fro= m each must be
=A0 =A0 =A0the same.

=A0 =A0 =A0If the client'= s certificate type is OpenPGP (RFC 6091), the
=A0 =A0 =A0NETCONF username is extracted from "User ID" field tha= t has been
=A0 =A0 =A0flagged as being the "Primary User ID" f= ield (RFC 4880). =A0The
=A0 =A0 =A0NETCONF username is the "local-p= art" of the "addr-spec" field
=A0 =A0 =A0(RFC 5322).

=A0 =A0 =A0The username provided by the implementatio= n of this document
=A0 =A0 =A0will be made available to the NETCONF mess= age layer as the NETCONF
=A0 =A0 =A0username without modification. =A0If= the username does not comply
=A0 =A0 =A0to the NETCONF requirements on usernames [I-D.ietf-netconf-4741b= is],
=A0 =A0 =A0i.e., the username is not representable in XML, the TLS = session
=A0 =A0 =A0MUST be dropped. =A0Any transformations applied to th= e authenticated
=A0 =A0 =A0identity of the TLS client made by the TLS server (e.g., via
= =A0 =A0 =A0authentication services or mappings to system accounts) are
= =A0 =A0 =A0outside the scope of this document.

=A0 =A0 =A0The = client's certificate SHOULD be signed by a certificate
=A0 =A0 =A0authority having a valid chain of trust to a certificate
=A0 = =A0 =A0authority the server trusts.


What do you think?

Th= anks,
Kent


=
--20cf304346d49abb0a04a4213a46-- From j.schoenwaelder@jacobs-university.de Wed May 25 17:10:25 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7322E06F1 for ; Wed, 25 May 2011 17:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk7UHaSda2l3 for ; Wed, 25 May 2011 17:10:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CBA0EE06AC for ; Wed, 25 May 2011 17:10:24 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2F1020D61; Thu, 26 May 2011 02:10:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hd4bOx7tUNfp; Thu, 26 May 2011 02:10:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C110F20D5F; Thu, 26 May 2011 02:10:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B497818BA96D; Thu, 26 May 2011 02:10:22 +0200 (CEST) Date: Thu, 26 May 2011 02:10:22 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110526001022.GC20483@elstar.local> Mail-Followup-To: Kent Watsen , Badra , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 00:10:25 -0000 On Wed, May 25, 2011 at 01:00:14PM -0700, Kent Watsen wrote: > NEW: > > 3.2. Client Identity > > The server MUST verify the identity of the client with using a > Client Certificate (RFC 5246, section 7.4.6). The client's > certificate MUST encode the NETCONF username as follows: > > If the client's certificate type is X.509 (RFC 5280), the NETCONF > username MUST be obtained from either the "CN" (Common Name) > "emailAddress", or "rfc822Name" fields. If the CN field is set, > then the NETCONF username is the value of CN field. If either > the emailAddress or rfc822Name fields are set, then the NETCONF > username is the "local-part" field (RFC 822). If more than one > of these fields are set, the NETCONF username from each must be > the same. It seems the way things are done in RFC 5953 is slightly different. For example, you propose to treat foo@here and foo@there to be the same NETCONF username foo. RFC 5953 seems to preserve the difference. RFC 5953 also has strong words the usage of CN is deprecated and I guess this is likely more reflecting current policy thinking than actual usage (but then don't ask me about these things ;-). > If the client's certificate type is OpenPGP (RFC 6091), the > NETCONF username is extracted from "User ID" field that has been > flagged as being the "Primary User ID" field (RFC 4880). The > NETCONF username is the "local-part" of the "addr-spec" field > (RFC 5322). Puh, RFC 5953 does ignore RFC 6091 certs... Out of curiosity, any information how much implementation support there is for OpenPGP certs? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Wed May 25 17:19:08 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E73E0680 for ; Wed, 25 May 2011 17:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp+Bw-5zB6SB for ; Wed, 25 May 2011 17:19:06 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40CE0670 for ; Wed, 25 May 2011 17:19:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTd2ccasKTO2kfYxCNTce3FWMCG2DwD6v@postini.com; Wed, 25 May 2011 17:19:06 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 25 May 2011 17:15:19 -0700 From: Kent Watsen To: Badra Date: Wed, 25 May 2011 17:15:15 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwbKyDJhv+b7wcxQxypLagrZRR4EgAAhHOQ Message-ID: <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 00:19:08 -0000 > Just a small comment on the following: > >=A0=A0=A0=A0 If more than one >=A0 =A0 =A0of these fields are set, the NETCONF username from each must be >=A0 =A0 =A0the same. >Does this mean that we have to carefully set all of those fields to the >same value (username) during the certificate generation? > > Isn't required to keep your early point on the CN;=20 >=20 > "The common name SHOULD be a uid (e.g., "kwatsen"), instead of full name = (e.g. "Kent Wasten")." I was trying to provide some flexibility - I don't know which of those 3 fi= elds people will want to use. Do you think it's too restrictive to requi= re them to be the same? Maybe some folks would want to set Common Name to = "Kent Watsen" while having rfc822Name "kwatsen@juniper.net"... Perhaps we = should replace the text to read: "If more than one of these fields are set= , the NETCONF server should attempt to use them in the following order: CN,= rfc822Name, emailAddress."? =20 Also, we should ensure that some fields are marked "critical". For instanc= e: subjectAltName=3Dcritical,rfc822Name:kwatsen@juniper.net BTW, I completely forgot to write anything about the CA setting a value for= what group the user can be mapped to. Maybe we could use the "otherName" = field, using an IANA-assigned OID under the "ietf-tree" (http://www.oid-inf= o.com/get/1.3.6.1.8.1)? For instance: subjectAltName=3Dcritical,rfc822Name:kwatsen@juniper.net,otherName:group= ;UTF8:my-group What do you think? From j.schoenwaelder@jacobs-university.de Wed May 25 21:42:56 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B393E0686 for ; Wed, 25 May 2011 21:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhj6xuEFv1ou for ; Wed, 25 May 2011 21:42:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 402CCE067C for ; Wed, 25 May 2011 21:42:54 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC53520D66; Thu, 26 May 2011 06:42:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h5Kl5KJx64mI; Thu, 26 May 2011 06:42:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E800420D62; Thu, 26 May 2011 06:42:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CA2C218BAA96; Thu, 26 May 2011 06:42:52 +0200 (CEST) Date: Thu, 26 May 2011 06:42:52 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110526044252.GA20828@elstar.local> Mail-Followup-To: Kent Watsen , Badra , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 04:42:56 -0000 On Wed, May 25, 2011 at 05:15:15PM -0700, Kent Watsen wrote: > Perhaps we should replace the text to read: "If more than one of > these fields are set, the NETCONF server should attempt to use them > in the following order: CN, rfc822Name, emailAddress."? As said before, this is what we ended up with in RFC 5953: [...] However, the usage of the CommonName field is deprecated and thus this usage is NOT RECOMMENDED. > BTW, I completely forgot to write anything about the CA setting a > value for what group the user can be mapped to. Maybe we could use > the "otherName" field, using an IANA-assigned OID under the > "ietf-tree" (http://www.oid-info.com/get/1.3.6.1.8.1)? For > instance: There is no requirement to provide a group. NACM has the concept of a group (=role) and the situation where this is provided to NACM is in principle RADIUS (Management-Policy-Id defined in RFC 5607). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Thu May 26 00:51:01 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44776E0670 for ; Thu, 26 May 2011 00:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVV-GTUu3kUx for ; Thu, 26 May 2011 00:51:00 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD28E065B for ; Thu, 26 May 2011 00:51:00 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTd4GX+rdS3g+oBx3+bjJNN/Zh0G7C00H@postini.com; Thu, 26 May 2011 00:51:00 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 26 May 2011 00:45:31 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Thu, 26 May 2011 00:45:31 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwbeONQjHoQARdaRdafnJZ82U/sIg== Message-ID: References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <20110526001022.GC20483@elstar.local> In-Reply-To: <20110526001022.GC20483@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 07:51:01 -0000 [top-posting since my phone didn't quote well last time] Regarding using the entire rfc822Name field (foo@here vs foo@there), this w= ould mean that all usernames would have to have the '@' character, per the = addr-spec format defined in RFC 822. But only using the local-part doesn't= restrict use of the '@' character, since it's allowed when in a quoted str= ing (e.g. "foo@bar"@domain). There is a convention for email address to be= "username@domain" (e.g. local-part =3D=3D username), since the @domain pa= rt is used primarily for Internet routing (virtual hosting aside). Was = this discussed with RFC 5953? Is this why RFC 5953 supports mappings for i= pAddress and dnsName? Should we support these other mappings as well? Regarding OpenPGP certificates, I've never seen it used, but the TLS RFC al= lows it, so it seemed prudent to have a mapping for it.=20 Thanks, Kent On May 25, 2011, at 8:10 PM, "Juergen Schoenwaelder" wrote: > On Wed, May 25, 2011 at 01:00:14PM -0700, Kent Watsen wrote: >> NEW: >>=20 >> 3.2. Client Identity >>=20 >> The server MUST verify the identity of the client with using a >> Client Certificate (RFC 5246, section 7.4.6). The client's >> certificate MUST encode the NETCONF username as follows: >>=20 >> If the client's certificate type is X.509 (RFC 5280), the NETCONF >> username MUST be obtained from either the "CN" (Common Name) >> "emailAddress", or "rfc822Name" fields. If the CN field is set, >> then the NETCONF username is the value of CN field. If either=20 >> the emailAddress or rfc822Name fields are set, then the NETCONF >> username is the "local-part" field (RFC 822). If more than one >> of these fields are set, the NETCONF username from each must be >> the same. >=20 > It seems the way things are done in RFC 5953 is slightly different. > For example, you propose to treat foo@here and foo@there to be the > same NETCONF username foo. RFC 5953 seems to preserve the difference. > RFC 5953 also has strong words the usage of CN is deprecated and I > guess this is likely more reflecting current policy thinking than > actual usage (but then don't ask me about these things ;-). >=20 >> If the client's certificate type is OpenPGP (RFC 6091), the >> NETCONF username is extracted from "User ID" field that has been >> flagged as being the "Primary User ID" field (RFC 4880). The >> NETCONF username is the "local-part" of the "addr-spec" field >> (RFC 5322). >=20 > Puh, RFC 5953 does ignore RFC 6091 certs... Out of curiosity, any > information how much implementation support there is for OpenPGP > certs? >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From kwatsen@juniper.net Thu May 26 01:15:31 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92013000A for ; Thu, 26 May 2011 01:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOsLBzRwggEJ for ; Thu, 26 May 2011 01:15:30 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F9E0688 for ; Thu, 26 May 2011 01:15:30 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTd4MHmpe3SxkkhzbcZbK/JxAzuLv0vBp@postini.com; Thu, 26 May 2011 01:15:30 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 26 May 2011 01:09:00 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Thu, 26 May 2011 01:08:56 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwbfCqWFYn7UkT8Q76NROB091Z8eQ== Message-ID: <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> <20110526044252.GA20828@elstar.local> In-Reply-To: <20110526044252.GA20828@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:15:31 -0000 Good point about Common Name being deprecated. Since emailAddress is also = deprecated, maybe we just say the NETCONF username MUST come from rfc822Nam= e? Even if we only allow the username to come from rfc822Name, x.509 allows fo= r multiple rfc822Names - any thoughts on how more than one should be handle= d? Dropping the group information sounds right, since the SSH transport doesn'= t provide an equivalent.=20 Thanks, Kent On May 26, 2011, at 12:42 AM, "Juergen Schoenwaelder" wrote: > On Wed, May 25, 2011 at 05:15:15PM -0700, Kent Watsen wrote: >=20 >> Perhaps we should replace the text to read: "If more than one of >> these fields are set, the NETCONF server should attempt to use them >> in the following order: CN, rfc822Name, emailAddress."? >=20 > As said before, this is what we ended up with in RFC 5953: >=20 > [...] However, the usage > of the CommonName field is deprecated and thus this usage is > NOT RECOMMENDED.=20 >=20 >> BTW, I completely forgot to write anything about the CA setting a >> value for what group the user can be mapped to. Maybe we could use >> the "otherName" field, using an IANA-assigned OID under the >> "ietf-tree" (http://www.oid-info.com/get/1.3.6.1.8.1)? For >> instance: >=20 > There is no requirement to provide a group. NACM has the concept of a > group (=3Drole) and the situation where this is provided to NACM is in > principle RADIUS (Management-Policy-Id defined in RFC 5607). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu May 26 01:38:38 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6F7E0723 for ; Thu, 26 May 2011 01:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0hFPLvUjnn1 for ; Thu, 26 May 2011 01:38:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 016D1E06B7 for ; Thu, 26 May 2011 01:38:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3940020D62; Thu, 26 May 2011 10:38:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2qhTzwJC0MP9; Thu, 26 May 2011 10:38:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34EF520D4D; Thu, 26 May 2011 10:38:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C81A18BACD1; Thu, 26 May 2011 10:38:36 +0200 (CEST) Date: Thu, 26 May 2011 10:38:35 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110526083835.GA21287@elstar.local> Mail-Followup-To: Kent Watsen , Badra , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <20110526001022.GC20483@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:38:38 -0000 On Thu, May 26, 2011 at 12:45:31AM -0700, Kent Watsen wrote: > [top-posting since my phone didn't quote well last time] > > Regarding using the entire rfc822Name field (foo@here vs foo@there), this would mean that all usernames would have to have the '@' character, per the addr-spec format defined in RFC 822. But only using the local-part doesn't restrict use of the '@' character, since it's allowed when in a quoted string (e.g. "foo@bar"@domain). There is a convention for email address to be "username@domain" (e.g. local-part == username), since the @domain part is used primarily for Internet routing (virtual hosting aside). Was this discussed with RFC 5953? Is this why RFC 5953 supports mappings for ipAddress and dnsName? Should we support these other mappings as well? I think RFC 5953 took the approach of making it configurable what is picked from a cert and then mapped into the SNMP equivalent of the NETCONF username. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu May 26 02:04:02 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908E4E06B2 for ; Thu, 26 May 2011 02:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxHXqS0w4luk for ; Thu, 26 May 2011 02:04:02 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 086B8E067B for ; Thu, 26 May 2011 02:04:02 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CD04676C26D; Thu, 26 May 2011 11:03:59 +0200 (CEST) Date: Thu, 26 May 2011 11:03:59 +0200 (CEST) Message-Id: <20110526.110359.1675264436984431529.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> References: <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> <20110526044252.GA20828@elstar.local> <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:04:02 -0000 Kent Watsen wrote: > Dropping the group information sounds right, since the SSH transport doesn't > provide an equivalent. I think it would be a feature for this transport to provide group mapping. It means you don't have to configure additional user -> group maps. NACM supports getting groups from the transport, so it fits nicely into the architecture. /martin From j.schoenwaelder@jacobs-university.de Thu May 26 02:15:01 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772A4E067B for ; Thu, 26 May 2011 02:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoM5u2jdeYWb for ; Thu, 26 May 2011 02:15:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A0F82E0664 for ; Thu, 26 May 2011 02:15:00 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0214120D6E; Thu, 26 May 2011 11:15:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WCIckNinPqTF; Thu, 26 May 2011 11:14:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B7F220D82; Thu, 26 May 2011 11:14:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC2A818BAE07; Thu, 26 May 2011 11:14:58 +0200 (CEST) Date: Thu, 26 May 2011 11:14:58 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110526091458.GB21380@elstar.local> Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <84600D05C20FF943918238042D7670FD3E7F500062@EMBX01-HQ.jnpr.net> <20110526044252.GA20828@elstar.local> <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> <20110526.110359.1675264436984431529.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110526.110359.1675264436984431529.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:15:01 -0000 On Thu, May 26, 2011 at 11:03:59AM +0200, Martin Bjorklund wrote: > Kent Watsen wrote: > > Dropping the group information sounds right, since the SSH transport doesn't > > provide an equivalent. > > I think it would be a feature for this transport to provide group > mapping. It means you don't have to configure additional user -> > group maps. NACM supports getting groups from the transport, so it > fits nicely into the architecture. With RADIUS, I thought the idea was that the identity of an SSH client can be mapped at authentication time into the current group (role) the identity has. This makes sense if roles change more frequently than the identity of a client (and its associated credentials). If we have the group (role) hard coded into a certificate, then we require to issue new certs whenever a group (role) of an identity changes. If the assumption is correct that roles change more frequently than identities (and their credentials), then coding the group into the cert seems probably wrong. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu May 26 02:21:22 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD27E06B6 for ; Thu, 26 May 2011 02:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGTWkp+TyJfM for ; Thu, 26 May 2011 02:21:22 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id ED6FEE06B2 for ; Thu, 26 May 2011 02:21:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E261476C399; Thu, 26 May 2011 11:21:20 +0200 (CEST) Date: Thu, 26 May 2011 11:21:19 +0200 (CEST) Message-Id: <20110526.112119.600552241751925428.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110526091458.GB21380@elstar.local> References: <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> <20110526.110359.1675264436984431529.mbj@tail-f.com> <20110526091458.GB21380@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:21:22 -0000 Juergen Schoenwaelder wrote: > On Thu, May 26, 2011 at 11:03:59AM +0200, Martin Bjorklund wrote: > > Kent Watsen wrote: > > > Dropping the group information sounds right, since the SSH > > > transport doesn't > > > provide an equivalent. > > > > I think it would be a feature for this transport to provide group > > mapping. It means you don't have to configure additional user -> > > group maps. NACM supports getting groups from the transport, so it > > fits nicely into the architecture. > > With RADIUS, I thought the idea was that the identity of an SSH client > can be mapped at authentication time into the current group (role) the > identity has. This makes sense if roles change more frequently than > the identity of a client (and its associated credentials). > > If we have the group (role) hard coded into a certificate, then we > require to issue new certs whenever a group (role) of an identity > changes. If the assumption is correct that roles change more > frequently than identities (and their credentials), then coding the > group into the cert seems probably wrong. We wouldn't _require_ the group info in the cert, but if it is there, it can be used. You could still use RADIUS or the NACM config mapping if you want to. /martin From j.schoenwaelder@jacobs-university.de Thu May 26 02:30:38 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BA4E0671 for ; Thu, 26 May 2011 02:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ4njFGAUGqK for ; Thu, 26 May 2011 02:30:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B2E0664 for ; Thu, 26 May 2011 02:30:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2B2E20D93; Thu, 26 May 2011 11:30:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id igy2Sh09RyB0; Thu, 26 May 2011 11:30:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02D1020D8E; Thu, 26 May 2011 11:30:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EB17E18BAEA5; Thu, 26 May 2011 11:30:35 +0200 (CEST) Date: Thu, 26 May 2011 11:30:35 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110526093035.GA21464@elstar.local> Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <0BF34357-F746-4D0E-BD7C-C2DD388387BB@juniper.net> <20110526.110359.1675264436984431529.mbj@tail-f.com> <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110526.112119.600552241751925428.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:30:38 -0000 On Thu, May 26, 2011 at 11:21:19AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, May 26, 2011 at 11:03:59AM +0200, Martin Bjorklund wrote: > > > Kent Watsen wrote: > > > > Dropping the group information sounds right, since the SSH > > > > transport doesn't > > > > provide an equivalent. > > > > > > I think it would be a feature for this transport to provide group > > > mapping. It means you don't have to configure additional user -> > > > group maps. NACM supports getting groups from the transport, so it > > > fits nicely into the architecture. > > > > With RADIUS, I thought the idea was that the identity of an SSH client > > can be mapped at authentication time into the current group (role) the > > identity has. This makes sense if roles change more frequently than > > the identity of a client (and its associated credentials). > > > > If we have the group (role) hard coded into a certificate, then we > > require to issue new certs whenever a group (role) of an identity > > changes. If the assumption is correct that roles change more > > frequently than identities (and their credentials), then coding the > > group into the cert seems probably wrong. > > We wouldn't _require_ the group info in the cert, but if it is there, > it can be used. You could still use RADIUS or the NACM config mapping > if you want to. But why would someone use this? What is the problem to be solved? Is creating certificates easier than configuring a NETCONF server? ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu May 26 03:01:15 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E80E068F for ; Thu, 26 May 2011 03:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT9IjUit9Faj for ; Thu, 26 May 2011 03:01:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id B8621E0671 for ; Thu, 26 May 2011 03:01:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C3DC976C4A7; Thu, 26 May 2011 12:01:13 +0200 (CEST) Date: Thu, 26 May 2011 12:01:12 +0200 (CEST) Message-Id: <20110526.120112.1416344284371929693.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110526093035.GA21464@elstar.local> References: <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> <20110526093035.GA21464@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:01:15 -0000 Juergen Schoenwaelder wrote: > On Thu, May 26, 2011 at 11:21:19AM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, May 26, 2011 at 11:03:59AM +0200, Martin Bjorklund wrote: > > > > Kent Watsen wrote: > > > > > Dropping the group information sounds right, since the SSH > > > > > transport doesn't > > > > > provide an equivalent. > > > > > > > > I think it would be a feature for this transport to provide group > > > > mapping. It means you don't have to configure additional user -> > > > > group maps. NACM supports getting groups from the transport, so it > > > > fits nicely into the architecture. > > > > > > With RADIUS, I thought the idea was that the identity of an SSH client > > > can be mapped at authentication time into the current group (role) the > > > identity has. This makes sense if roles change more frequently than > > > the identity of a client (and its associated credentials). > > > > > > If we have the group (role) hard coded into a certificate, then we > > > require to issue new certs whenever a group (role) of an identity > > > changes. If the assumption is correct that roles change more > > > frequently than identities (and their credentials), then coding the > > > group into the cert seems probably wrong. > > > > We wouldn't _require_ the group info in the cert, but if it is there, > > it can be used. You could still use RADIUS or the NACM config mapping > > if you want to. > > But why would someone use this? What is the problem to be solved? Is > creating certificates easier than configuring a NETCONF server? ;-) I thought Kent had a use case, and I thought that the reasoning that it shouldn't be here b/c SSH doesn't have it was not convincing. If we don't see a use case, it should of course not be included. (But you should probably not ask me, since I don't really see the use case with client certificates in the first place. I don't think this TLS transport provides any benefits over the SSH transport.) /martin From kwatsen@juniper.net Thu May 26 05:48:23 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13677130028 for ; Thu, 26 May 2011 05:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlVkadIDptJq for ; Thu, 26 May 2011 05:48:22 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 180CA130018 for ; Thu, 26 May 2011 05:48:12 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTd5MByWCpzQZvVQ6Mo7tzYLlmMtcdkqW@postini.com; Thu, 26 May 2011 05:48:13 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 26 May 2011 05:43:27 -0700 From: Kent Watsen To: Martin Bjorklund Date: Thu, 26 May 2011 05:43:24 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: AcwbooJbRaGWWVM5QYOs4OeFepuqKA== Message-ID: <599FC8D7-FA6C-4E2D-A6BF-AF5E8AAD910B@juniper.net> References: <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> <20110526093035.GA21464@elstar.local> <20110526.120112.1416344284371929693.mbj@tail-f.com> In-Reply-To: <20110526.120112.1416344284371929693.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 12:48:23 -0000 The use case is much like with RADIUS, mapping an unknown user to a known g= roup, but without the need to deploy a RADIUS server. If a company is usin= g PKI, presumably they could set up infrastructure to quickly generate/revo= ke client certs when roles change. =20 That said, Martin is right about this transport not having anything on SSH,= especially given that SSH now supports client/server certs (RFC 6187). Ac= tually, this transport is arguably worse than SSH given the lack of useraut= h and no multiplexing solution like SSH channels (BEEP doesn't count). It seems that how to use x.509 client certs to encode identity could be it'= s own RFC that this RFC would then reference. An RFC like that might be us= eful for HTTPS, POPS, IMAPS, etc.=20 Thanks, Kent On May 26, 2011, at 6:01 AM, "Martin Bjorklund" wrote: > Juergen Schoenwaelder wrote: >> On Thu, May 26, 2011 at 11:21:19AM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> On Thu, May 26, 2011 at 11:03:59AM +0200, Martin Bjorklund wrote: >>>>> Kent Watsen wrote: >>>>>> Dropping the group information sounds right, since the SSH >>>>>> transport doesn't=20 >>>>>> provide an equivalent. >>>>>=20 >>>>> I think it would be a feature for this transport to provide group >>>>> mapping. It means you don't have to configure additional user -> >>>>> group maps. NACM supports getting groups from the transport, so it >>>>> fits nicely into the architecture. >>>>=20 >>>> With RADIUS, I thought the idea was that the identity of an SSH client >>>> can be mapped at authentication time into the current group (role) the >>>> identity has. This makes sense if roles change more frequently than >>>> the identity of a client (and its associated credentials). >>>>=20 >>>> If we have the group (role) hard coded into a certificate, then we >>>> require to issue new certs whenever a group (role) of an identity >>>> changes. If the assumption is correct that roles change more >>>> frequently than identities (and their credentials), then coding the >>>> group into the cert seems probably wrong. >>>=20 >>> We wouldn't _require_ the group info in the cert, but if it is there, >>> it can be used. You could still use RADIUS or the NACM config mapping >>> if you want to. >>=20 >> But why would someone use this? What is the problem to be solved? Is >> creating certificates easier than configuring a NETCONF server? ;-) >=20 > I thought Kent had a use case, and I thought that the reasoning that > it shouldn't be here b/c SSH doesn't have it was not convincing. If > we don't see a use case, it should of course not be included. (But > you should probably not ask me, since I don't really see the use case > with client certificates in the first place. I don't think this TLS > transport provides any benefits over the SSH transport.) >=20 >=20 > /martin From wjhns1@hardakers.net Thu May 26 07:37:09 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED3E0759 for ; Thu, 26 May 2011 07:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvoPuFvfwBgG for ; Thu, 26 May 2011 07:37:07 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id B4C45E0754 for ; Thu, 26 May 2011 07:37:07 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 03C98338; Thu, 26 May 2011 07:36:34 -0700 (PDT) From: Wes Hardaker To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <20110526001022.GC20483@elstar.local> <20110526083835.GA21287@elstar.local> Date: Thu, 26 May 2011 07:36:33 -0700 In-Reply-To: <20110526083835.GA21287@elstar.local> (Juergen Schoenwaelder's message of "Thu, 26 May 2011 10:38:35 +0200") Message-ID: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:37:09 -0000 >>>>> On Thu, 26 May 2011 10:38:35 +0200, Juergen Schoenwaelder said: >> There is a convention for email address to be "username@domain" >> (e.g. local-part == username), since the @domain part is used >> primarily for Internet routing (virtual hosting aside). Was this >> discussed with RFC 5953? Is this why RFC 5953 supports mappings for >> ipAddress and dnsName? Should we support these other mappings as >> well? JS> I think RFC 5953 took the approach of making it configurable what is JS> picked from a cert and then mapped into the SNMP equivalent of the JS> NETCONF username. The 5953 certificate mapping was done to allow for flexibility so operators could do what they wanted using certificates they already had available to them without needing to create new ones. In many cases, it was expected that it wasn't necessarily a human even making the connection, hence an IP address based certificate might do a better job identifying what exactly was making the connection. The proposals in this thread seem to be taking the opposite approach: limit what the certificate can look like restricting it so that it must be created specifically to meet the needs of netconf and thus it's likely operators will need a "netconf" certificate that is very different than the rest of the certificates they might already have available to them. It also appears that "there will be only one CA" as well, based on the discussion texts so far. I haven't chimed in much because I'm having a hard time trying to figure out what the real end goals are: restrictive vs permissive, one CA vs multiple, reuse vs "only for netconf", etc. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu May 26 11:18:29 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E5E130048 for ; Thu, 26 May 2011 11:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhGtMWwjfDTr for ; Thu, 26 May 2011 11:18:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 65B10130041 for ; Thu, 26 May 2011 11:18:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E124220D42; Thu, 26 May 2011 20:18:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KNTHEOuET2xn; Thu, 26 May 2011 20:18:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BA4220D3E; Thu, 26 May 2011 20:18:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1994B18BB25C; Thu, 26 May 2011 20:18:24 +0200 (CEST) Date: Thu, 26 May 2011 20:18:24 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20110526181824.GA21638@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> <20110526093035.GA21464@elstar.local> <20110526.120112.1416344284371929693.mbj@tail-f.com> <599FC8D7-FA6C-4E2D-A6BF-AF5E8AAD910B@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <599FC8D7-FA6C-4E2D-A6BF-AF5E8AAD910B@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 18:18:29 -0000 On Thu, May 26, 2011 at 05:43:24AM -0700, Kent Watsen wrote: > The use case is much like with RADIUS, mapping an unknown user to a > known group, but without the need to deploy a RADIUS server. If a > company is using PKI, presumably they could set up infrastructure to > quickly generate/revoke client certs when roles change. And that is simpler than simply changing the ACL configuration? > That said, Martin is right about this transport not having anything > on SSH, especially given that SSH now supports client/server certs > (RFC 6187). Actually, this transport is arguably worse than SSH > given the lack of userauth and no multiplexing solution like SSH > channels (BEEP doesn't count). True, if you have SSH, which you must have since NETCONF requires it as mandatory to implement transport. That said, there likely will be a class of devices that have TLS but no SSH and where adding SSH support just for NETCONF is a significant cost factor - or a reason to not use NETCONF. The question is whether we care about this or not. Whatever we do, I think we should either make the TLS transport usable or take the decision to move this off the standards-track instead of doing half-baked updates that won't work in practice. Perhaps time to check how many implementations and deployments we have for the non-SSH transports? > It seems that how to use x.509 client certs to encode identity could > be it's own RFC that this RFC would then reference. An RFC like > that might be useful for HTTPS, POPS, IMAPS, etc. Who uses client certs with HTTPS, POPS, IMAPS? What would be more seriously needed is an addition to TLS that provides us with different user auth mechanisms within TLS... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Thu May 26 11:50:18 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3FBE06DF for ; Thu, 26 May 2011 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loENaJZ98MtG for ; Thu, 26 May 2011 11:50:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C736E068C for ; Thu, 26 May 2011 11:50:17 -0700 (PDT) Received: by vws12 with SMTP id 12so993147vws.31 for ; Thu, 26 May 2011 11:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=nQREm3kwy7Jgy1udziHcQMfMFrxc7f6bjc1BSzxlm1U=; b=M76VzBbr/RND0V/uq1RaJL1anTKtHBe2Ne12XclqO9P+SRermQtfT8usXqgEb7rp2X lT65YWxithE4AqeQjpH+UZweJV8iDd4StAH/vA9SuBakHUrwdoXv9wNFWivP1F6af1wH drxqODcWykOr8NElxbYSp/Y96IKsqAcdVcOpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nJyh1mqfnqEAevQB2VvJ+HHSGRihWxMzkSvYTt8OdG9hqm/y0Br32SzV6lPBM06Xk3 ySaS9QIc4lYeuGlpbZq0iVksJHVuKWd/WnDnDW4X+TRq5N3mYZ2osVJMJ2AgpPIcTcRV oTJqVrJtgInLFaAbLnDLriPLsQFwojkwSb2XY= MIME-Version: 1.0 Received: by 10.52.176.68 with SMTP id cg4mr1609349vdc.300.1306435817271; Thu, 26 May 2011 11:50:17 -0700 (PDT) Received: by 10.220.185.198 with HTTP; Thu, 26 May 2011 11:50:17 -0700 (PDT) In-Reply-To: <20110526001022.GC20483@elstar.local> References: <84600D05C20FF943918238042D7670FD3E7F36187A@EMBX01-HQ.jnpr.net> <20110525001155.GA2121@elstar.local> <6231D6EE-35CB-4786-BCD2-CC4E73686BAD@juniper.net> <84600D05C20FF943918238042D7670FD3E7F362307@EMBX01-HQ.jnpr.net> <84600D05C20FF943918238042D7670FD3E7F3625D1@EMBX01-HQ.jnpr.net> <20110526001022.GC20483@elstar.local> Date: Thu, 26 May 2011 20:50:17 +0200 Message-ID: From: Badra To: Juergen Schoenwaelder , Kent Watsen , Badra , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5016653cf72f204a4324a2c Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 18:50:19 -0000 --bcaec5016653cf72f204a4324a2c Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 26, 2011 at 2:10 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, May 25, 2011 at 01:00:14PM -0700, Kent Watsen wrote: > > NEW: > > > > 3.2. Client Identity > > > > The server MUST verify the identity of the client with using a > > Client Certificate (RFC 5246, section 7.4.6). The client's > > certificate MUST encode the NETCONF username as follows: > > > > If the client's certificate type is X.509 (RFC 5280), the NETCONF > > username MUST be obtained from either the "CN" (Common Name) > > "emailAddress", or "rfc822Name" fields. If the CN field is set, > > then the NETCONF username is the value of CN field. If either > > the emailAddress or rfc822Name fields are set, then the NETCONF > > username is the "local-part" field (RFC 822). If more than one > > of these fields are set, the NETCONF username from each must be > > the same. > > It seems the way things are done in RFC 5953 is slightly different. > For example, you propose to treat foo@here and foo@there to be the > same NETCONF username foo. RFC 5953 seems to preserve the difference. > RFC 5953 also has strong words the usage of CN is deprecated and I > guess this is likely more reflecting current policy thinking than > actual usage (but then don't ask me about these things ;-). Since there is no loop iterating over a set of usernames, so how exporting the first subjectAltName field? Like that we avoid restrictions on reusing certificates (but need to restrict the NETCONF usernqmes to this field content) Best regards Badra --bcaec5016653cf72f204a4324a2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, May 26, 2011 at 2:10 AM, Juergen Schoenw= aelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, May 25, 2011 at 01:00:14PM -0700, Kent Watsen wro= te:
> NEW:
>
> =A0 =A03.2. Client Identity
>
>= ; =A0 =A0 =A0 The server MUST verify the identity of the client with using = a
> =A0 =A0 =A0 Client Certificate (RFC 5246, section 7.4.6). =A0The = client's
> =A0 =A0 =A0 certificate MUST encode the NETCONF username as follows:>
> =A0 =A0 =A0 If the client's certificate type is X.509 (R= FC 5280), the NETCONF
> =A0 =A0 =A0 username MUST be obtained from ei= ther the "CN" (Common Name)
> =A0 =A0 =A0 "emailAddress", or "rfc822Name" fields= . =A0If the CN field is set,
> =A0 =A0 =A0 then the NETCONF username = is the value of CN field. =A0If either
> =A0 =A0 =A0 the emailAddress= or rfc822Name fields are set, then the NETCONF
> =A0 =A0 =A0 username is the "local-part" field (RFC 822). = =A0If more than one
> =A0 =A0 =A0 of these fields are set, the NETCON= F username from each must be
> =A0 =A0 =A0 the same.

It = seems the way things are done in RFC 5953 is slightly different.
For example, you propose to treat foo@here and foo@there to be the
same = NETCONF username foo. RFC 5953 seems to preserve the difference.
RFC 595= 3 also has strong words the usage of CN is deprecated and I
guess this i= s likely more reflecting current policy thinking than
actual usage (but then don't ask me about these things ;-).
=A0
Since there is no loop iterating over a set of u= sernames, so how exporting the first subjectAltName field? Like that we avo= id restrictions on reusing certificates (but need to restrict the NETCONF u= sernqmes to this field content)

Best regards
Badra
--bcaec5016653cf72f204a4324a2c-- From kwatsen@juniper.net Fri May 27 16:10:43 2011 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137D9E0711 for ; Fri, 27 May 2011 16:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d6tYRm4y-AA for ; Fri, 27 May 2011 16:10:36 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 192BEE06A7 for ; Fri, 27 May 2011 16:10:36 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTeAvaNNkUjqx6XRE0EVnPoyJYEJoon8f@postini.com; Fri, 27 May 2011 16:10:36 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 27 May 2011 16:09:41 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Fri, 27 May 2011 16:09:38 -0700 Thread-Topic: [Netconf] Updating NETCONF over TLS document (RFC5539) Thread-Index: Acwb0VBxCO+j+7orQlGmebF5IPiqLAA3pE0A Message-ID: <84600D05C20FF943918238042D7670FD3E7F64D7ED@EMBX01-HQ.jnpr.net> References: <20110526091458.GB21380@elstar.local> <20110526.112119.600552241751925428.mbj@tail-f.com> <20110526093035.GA21464@elstar.local> <20110526.120112.1416344284371929693.mbj@tail-f.com> <599FC8D7-FA6C-4E2D-A6BF-AF5E8AAD910B@juniper.net> <20110526181824.GA21638@elstar.local> In-Reply-To: <20110526181824.GA21638@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 23:10:43 -0000 > And that is simpler than simply changing the ACL configuration? For one device, no, but maybe for a network of devices. Of course, to your point, if they have a network of devices, it's more likely they'll have a RADIUS server. > True, if you have SSH, which you must have since NETCONF requires it > as mandatory to implement transport. That said, there likely will be a > class of devices that have TLS but no SSH and where adding SSH support > just for NETCONF is a significant cost factor - or a reason to not use > NETCONF. The question is whether we care about this or not. Good point. *If* there were such a class of devices, it would matter=20 to a NETCONF-oriented NMS (like ours!) - as managing the device through=20 NETCONF/TLS would be easier than adapting whatever native interface=20 it presents. > Whatever we do, I think we should either make the TLS transport usable > or take the decision to move this off the standards-track instead of > doing half-baked updates that won't work in practice. Perhaps time to > check how many implementations and deployments we have for the non-SSH > transports? Agreed > Who uses client certs with HTTPS, POPS, IMAPS?=20 A quick search reveals more than I suspected. Both Firefox and Mozilla support "personal certificates" and both Apache and DoveCot can be=20 configured to authenticate client certificates. A number of institutions (labs, schools, etc.) run CAs to issue personal certificates. Some issue client certificates for as little as 7 days. This page=20 (http://itc.virginia.edu/netbadge) shows how a university uses personal certificates to grant access to "website, service, or application" -=20 apparently they're using Pubcookie (http://www.pubcookie.org/). Should the TLS transport require a call out to an identity server to produce=20 a NetConf username from the certificate? > What would be more > seriously needed is an addition to TLS that provides us with different > user auth mechanisms within TLS... Your suggestion to add the user auth mechanisms to TLS itself is along=20 the lines of what I meant by saying that the effort (if any) should be=20 factored into another standard - as having a NetConf-specific solution wouldn't be ideal...