Re: [OPSAWG] [OPSEC] Fwd: New Version Notification for draft-winter-opsec-netconfig-metadata-00.txt

[Stefan Winter <[e-mail]>]

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: [phone]
Fax: [phone]

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