Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt
Stefan Winter <stefan.winter@restena.lu> Fri, 15 July 2016 11:13 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A186E12D766; Fri, 15 Jul 2016 04:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp7qat-rQgvA; Fri, 15 Jul 2016 04:13:24 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE8612D741; Fri, 15 Jul 2016 04:13:23 -0700 (PDT)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 478B243AE9; Fri, 15 Jul 2016 13:13:22 +0200 (CEST)
From: Stefan Winter <stefan.winter@restena.lu>
To: Christian Franke <nobody@nowhere.ws>, IETF OPSEC <opsec@ietf.org>
References: <20160321092737.6013.75371.idtracker@ietfa.amsl.com> <56EFBF2D.5090904@restena.lu> <5707B4D9.9010508@nowhere.ws>
Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Message-ID: <3567108c-b59b-17ef-bb28-694b625ccb12@restena.lu>
Date: Fri, 15 Jul 2016 13:13:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <5707B4D9.9010508@nowhere.ws>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="seBXAim4TodHeGsD5hKr6UBImAi1WmUI4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/nMd4-P9F6g_Z7wGKP-ubyRZmXVE>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2016 11:13:26 -0000
Hi, > I have just read through your draft. In my opinion, it would be very > useful to have a standardized way to provide configuration profiles to > users. Looking through the draft and the yang file, I came up with the > following notes: Thanks for these! Answers inline: > Comments on the draft: > - it would be useful if subject alt match could be configured > for usage with e.g. EAP-TTLS The settings in the draft are generic in the sense that they apply to multiple EAP methods (and possibly non-EAP uses). The ServerSideCredential/ServerID in particular contains the abstract notion of "the name of the server". It is up to the EAP method to define which property of the incoming certificate, or what else, is matched against that (method-agnostic) name. As an example, Microsoft's PEAP spec pinpoint the Common Name - i.e. the EAP method does not allow subjectAltName to be used for matching. There is no leeway to tell via config file that you'd /wish/ the subjectAltName is used if the EAP method's spec does not allow it. TTLS (RFC5281) by contrary does not specify whether Common Name or subjectAltName is used; this is left to the implementation. TEAP (RFC7170) in its 7.6 specifies that subjectAltName is to be used (with a fallback to NO validation) - the Common Name is not even considered. EAP-pwd (RFC5931) has the notion of a server identity, but the EAP method does not make use of PKI certificates, and has neither a Common Name nor a subjectAltName to check against. It has its own provisions in the protocol to send a server name to the EAP peer. These examples illustrate that it's the EAP method's business to define what a "server name" is and how it's supposed to be checked. So, indicating this in config during provisioning time actually seems not very useful. I reckon I can collapse ServerName and ServerHandle BTW, they nicely coincide in this abstract thinking. > - how would the private key for a client certificate be stored, > also in `cert-data`? I don't see another suitable field Yes; the file format would be P12. > - which information does `allow-save` apply to? If it applies to > the private key of a client certificate, how would public > key authentication work without storing it? It applies to the Password and/or Passphrase elements, if present. It is up to the implementation if Passphrase allow-save leads to a) the encrypted private key stored along with the decrytion passphrase b) the unencrypted private key gets stored in a credential store (because storing the encrypted data and the key to it together does not provide material extra security over unencrypted storage in the first place) The question of an unencrypted private key in the config file does not arise - there are only three formats specified: PEM and DER do not carry private keys, an P12 requires a passphrase. > - can you provide a usecase for the `valid-until` field? Absolutely! Credentials expire after a while. If you bought a Wi-Fi access scratch card for two weeks, then the account will stop working after two weeks. BUT: your device does not know that. It has a saved connection and will try to authenticate with this username and password for eternity. On the client side, this bumping into walls drains battery etc. On the server side, over time more and more expired accounts build up and hammer the server with TLS negotiations which are bound to fail. The cryptographic operations make the server more and more busy over time, for no reason. This is a real-life problem. So, if you know about the longevity of the credential at provisioning time, it is very useful to tell the device about it. The device can then decide to delete the config at that point in time, or at least to watch the authn states in the future: consistent rejected auths past the valid-until time should lead to de-provisioning or asking the user to investigate his account. Writing all this, maybe it would be useful to beef this up in the sense of having an extra qualifier "Hard Expiry" (=device can automatically delete credential at point in time) and "Soft Expiry" (=device should merely start to become suspicious and watch out for continuous failed auths). That latter case could be a student account initially valid for one semester, but the student /may/ have re-enrolled, keeping the account active. > - it is not obvious to me how the current model applies to VPN or > E-Mail Server connections as named in the draft VPN needs more work for sure. And I tend to think it's better to forget about E-Mail; it's a rathole for gazillions of services and the spec would quickly become unmanageable. Concentrating at network connectivity is probably the best way forward. > - it is not clear to me how an anonymous identify for EAP-TTLS or > EAP-PEAP would be configured That would be AuthenticationMethod / EAPClientSideCredential / AnonymousIdentity while the actual user identifier is in AuthenticationMethod / InnerAuthenticationMethod / EAPClientSideCredential / (reference to ClientSideCredential) > - I think it would be useful to have some consideration, either in > this or another document, about how the files procuded according to > this model should be processed, i.e. requirements on how their > authenticity must be verified, how they should be displayed to the > users and in what configuration they should actually result. True. You will have noticed chapter 4 on Issuer Authentication, Integrity Protection and Encryption: "Decisions TBD" :-) UI is also worth considering; e.g. unauthenticated files should be presented with a warning that all the content could be a lie from someone you don't know (hiding or marginalising the ProviderInfo elements); authenticated ones could prominently display the name and logo of the provider, etc. > Yang related: > - there is a type leafref which should probably used when referring > to config parts by UUID > - there are types for ipv4 and ipv6 addresses that should be used > instead of string > - list IPAddress has dynamic and static as keys, keys need to be > unique, so how to enable both dhcpv4 and dhcpv6? Same thing e.g. > for DNS All of those are due to my ignorant misunderstanding of YANG :-) In particular the last one gave me headache and I submitted this rev knowing it's not good: The "IPAddress" field should be allowed to contain numerous occurences of DynamicAddress and/or StaticAddress. I don't want it to need a key for that, but YANG seems to insist on this. Same for StaticAddress: this can be an IPv4 XOR an IPv6 address, and should be allowed to occur multiple times. list leaf IPAddress "string" kind of got the job done, but lacks some sophistication. In short: I'm in need of a YANG expert :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- [OPSEC] Fwd: New Version Notification for draft-w… Stefan Winter
- Re: [OPSEC] Fwd: New Version Notification for dra… Stefan Winter
- Re: [OPSEC] Fwd: New Version Notification for dra… Christian Franke