X.509 and ssh - SSH

This is a discussion on X.509 and ssh - SSH ; "JKV" writes: > I would like to use it the other way around. All users presenting a > X.509 certificate issued by a trusted party can access the > server. Then I only need to install the root certificate of ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 66

Thread: X.509 and ssh

  1. Re: X.509 and ssh

    "JKV" writes:
    > I would like to use it the other way around. All users presenting a
    > X.509 certificate issued by a trusted party can access the
    > server. Then I only need to install the root certificate of the
    > trusted party on the server and the user management doesn't need to
    > be done on that server but can be done independently.


    but do you also need to install userid and/or any user specific
    permissions on the server?

    can any certificate from any trusted party be used to access the
    server ... or can only specific entities with specific kind of
    certificates from specific trusted parties be allowed to access the
    server.

    i've frequently asserted that the stale, static certificates are
    redundant and superfluous if

    1) the server has to have some sort of table or repository for allowed
    users ... i.e. for instance out of all possible entities getting
    certificates from some set of trusted parties ... which specific
    parties are actually allowed to access the system and/or possibly
    which permissions are allowed specific parties. this is kerberos type
    protocol (also used in windows platforms). one of the counter
    scenarios is that anybody with a certificate issued by an allowed
    trusted party can have access to your system (regardless of who they
    are). of course, then you may have a table of just those entities that
    can have access to your system; however, it you have table of which
    specific entities ... and potentially their permissions, then the
    certificates are again redundant and superfluous).

    2) the server can have access to the same table or repository
    maintained by the trusted party (since typically a trusted party
    issuing certificates needs some sort of table or repository that
    provide some information about the entities for which they are issuing
    certificates). on trivial example of this is the RADIUS protocol
    originally developed for giving modem server/concentrators (router
    type devices) access to the repository of entities, the associated
    authentication, allowed permissions, and possible accounting
    information (authentication, authorization, accounting).

    the trivial scenario for certificates is where you don't care about
    distinquishing between individuals ... that you treat all individuals
    exactly alike, don't actually need to know who they are ... and just
    need to know that they are member of the set of allowed individuals
    (this is the offline physical door badge access system) ... and that
    are only dealing with a specific trusted party that will only be
    issuing certifcates for the set of your allowed individuals.

    the original offline door badge systems were only a slight step up
    from the physical keying (i.e. the badges and the keys both
    represented "something you have" authentication as well as the means
    of permissions/authborizations ... aka access). however, these early
    badges, while somewhat harder to counterfeit than physical keys
    .... still provided no individual differentiation.

    in nearly the same time-frame as permissions were starting to be added
    to badges (allowing different badges to have potentially unique door
    access permissions), online systems door badge systems were also
    appearing. the value infrastructures fairly quickly migrated to online
    operation ... the badge was solely "something you have" autnetication
    .... and specific entity permissions (for specific door access)
    migrated to online information (rather being implicit in the badge).
    misc. past posts regarding 3-factor authentication
    http://www.garlic.com/~lynn/subpubkey.html#3factor

    the offline badge systems quickly become relegated to no-value
    infrastructures (as value infrastructures migrated to online badge
    systems that were rapidly decreasing in costs).

    the x.509 identity certificates somewhat saw the resurgance in the
    offline door badge acces paradigm from this earlier era (for no value
    operations). you also saw some organizations pushing x.509v3
    extensions for encoding permissions ... as a return to the brief
    period where door access permissions were encoded in the badge before
    the advent of online access systems took over for infrastructures with
    value operations (and the badge become purely authentication and all
    permissions and authorization characterists were encoded separately in
    online infrastructures).

    this is the scenario where certificates become redundant and
    superfluous for operations of value. the ability to generate a digital
    signature implies the possesion of the corresponding private key (as
    "something you have" authentication). the verification of the digital
    signature is done with a public key stored with the permissions and
    authorizations for the entity.

    misc past posts characterizing public key systems as "something you
    have" authentication ... aka an entity uniquely possesess a specific
    private key
    http://www.garlic.com/~lynn/aadsm18.htm#23 public-key: the wrong model for email?
    http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
    http://www.garlic.com/~lynn/2000f.html#14 Why trust root CAs ?
    http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
    http://www.garlic.com/~lynn/2005i.html#26 The Worth of Verisign's Brand
    http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
    http://www.garlic.com/~lynn/2005j.html#0 private key encryption - doubts
    http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
    http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
    http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
    http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
    http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
    http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
    http://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email
    http://www.garlic.com/~lynn/2005m.html#37 public key authentication
    http://www.garlic.com/~lynn/2005m.html#45 Digital ID
    http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
    http://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov
    http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
    http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
    http://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
    http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
    http://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question
    http://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question
    http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
    http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
    http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
    http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
    http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
    http://www.garlic.com/~lynn/2005v.html#5 famous literature

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  2. Re: X.509 and ssh

    "Richard E. Silverman" writes:

    >That's not quite true. Although X.509 is not part of the final SSH-TRANS
    >RFC, X.509 key types were defined in earlier drafts (as you note later in
    >this thread). Both Tectia and VShell use those key types (x509v3-sign-rsa
    >and x509v3-sign-dsa) as specified in that draft, so I don't believe there
    >is any need to reverse engineer anything. If you think there is, please
    >explain.


    The formats were so poorly specified that it wasn't possible to create an
    interoperable implementation from them. In fact, no-one seemed to be able to
    agree on what the formats should really be, probably due at least to some
    extent to the fact that everyone was interpreting the spec differently. The
    rather bizarre comment from a previous poster in this thread that I'm "against
    X.509" probably comes from the fact that I pointed out that the spec as it
    existed at the time was unimplementable, meaning that the text would either
    have to be clarified or removed. Since no-one was interested in clarifying
    it, it was removed. What's left is an expired draft (see
    http://datatracker.ietf.org/public/i...etail&id=13023)
    covering this.

    Presumably what's in this expired draft is what Tectia and VShell do (since
    one of the authors is from VanDyke and the other from F-Secure), however at
    the time the format was still specified in SSH-TRANS the text was so unclear
    that the only way to implement it was either (1) get really lucky in guessing
    what the text was supposed to mean or (2) reverse-engineer Tectia or VShell's
    handshake to see what they did.

    Peter.


  3. Re: X.509 and ssh

    "JKV" writes:

    >I would like to use it the other way around. All users presenting a X.509
    >certificate issued by a trusted party can access the server. Then I only
    >need to install the root certificate of the trusted party on the server and
    >the user management doesn't need to be done on that server but can be done
    >independently.


    Then all you need to do is arrange the small matter of managing a PKI
    alongside SSH.

    Somehow I think this isn't going in the right direction :-).

    Peter.


  4. Re: X.509 and ssh

    >>>>> "Chuck" == Chuck writes:

    Chuck> Couldn't something be built into the protocol to distribute
    Chuck> known_hosts? For example I connect to server X, it's
    Chuck> fingerprint matches the one I have on file, therefore I trust
    Chuck> it and it pushes down a list of all the hosts it trusts? If
    Chuck> there are any new ones, I get them the next time I connect to
    Chuck> the server.

    This would be an application issue, not a protocol addition, since the
    whole business of hostkey representation and validation is
    implementation-dependent and outside the scope of the protocol. Moreover,
    I think this misses the point: I was talking about the need for scalable,
    manageable method of automatically verifying all hosts in an
    administrative domain. Your idea applies to the existing known-host file,
    which mechanism is exactly the problem.

    --
    Richard Silverman
    res@qoxp.net


  5. Re: X.509 and ssh

    Richard E. Silverman sez:
    >>>>>> "Chuck" == Chuck writes:

    >
    > Chuck> Couldn't something be built into the protocol to distribute
    > Chuck> known_hosts? For example I connect to server X, it's
    > Chuck> fingerprint matches the one I have on file, therefore I trust
    > Chuck> it and it pushes down a list of all the hosts it trusts? If
    > Chuck> there are any new ones, I get them the next time I connect to
    > Chuck> the server.
    >
    > This would be an application issue, not a protocol addition, since the
    > whole business of hostkey representation and validation is
    > implementation-dependent and outside the scope of the protocol. Moreover,
    > I think this misses the point: I was talking about the need for scalable,
    > manageable method of automatically verifying all hosts in an
    > administrative domain.


    Add DS record (like MX, for ldap directory server) to DNS. Include
    host keys in host's ldap record.

    We could do SPF the same way, too.

    The problems here are opening ldap server to the world, replacing
    verisign with ldap server's administrator, standardizing use of
    encryption which may be illegal in some jurisdictions, etfc.
    Never gonna happen.

    Dima
    --
    Backwards compatibility is either a pun or an oxymoron. -- PGN

  6. Re: X.509 and ssh

    Dimitri Maziuk writes:
    > Add DS record (like MX, for ldap directory server) to DNS. Include
    > host keys in host's ldap record.
    >
    > We could do SPF the same way, too.
    >
    > The problems here are opening ldap server to the world, replacing
    > verisign with ldap server's administrator, standardizing use of
    > encryption which may be illegal in some jurisdictions, etfc.
    > Never gonna happen.


    you don't need to do encryption ... all you need to do is public key
    and digital signature as part of authentication.

    one of the issues when working x9.59 financial standard (aka the x9a10
    working group was given the requirement to preserve the integrity of
    the financial infrastructure for all retail payment transactions) was
    being able to do simple authentication w/o requiring encryption and/or
    other heavy duty operations.
    http://www.garlic.com/~lynn/x959.html#x959

    this resulted in simple digital signature on a retail payment
    transactions ... and the signing entity having a public key on file
    with their financial infrastructure.

    one of the other issues has been a major exploit of retail payment
    transactions is skimming the account number and using it in fraudulent
    transactions (and all the references to data breaches and account
    fraud, being able to do fraudulent transactions with harvested account
    numbers)
    http://www.garlic.com/~lynn/subpubkey.html#fraud

    so the other part of x9.59 was a business rule that account numbers
    used in x9.59 transactions were not valid in non-authenticated
    transactions. this is the issue that account numbers are used in large
    number of business processes (besides the basic transaciton) and
    even if you were to bury the world under miles of encryption ..
    you still couldn't eliminate account number leakage ... slightly
    related post on security proportional to risk
    http://www.garlic.com/~lynn/2001h.html#61

    in the x9.59 scenario ... you is possible for the related account
    numbers to leak all over the place ... and crooks still can't use them
    in fraudulent financial transactions (that haven't been digitally
    signed with the correct private key).

    so some of the historical lore is that the original x.500 dap was
    suppose to have lots of individual personal information. however,
    having enormous amounts of personal information in one place and
    publicly available is an enormous privacy issue. so along comes x.509
    identity certificate ... that also can contain enormous amounts of
    personal information ... but at least they aren't all located in one
    place. however, by the mid-90s, you started finding institutions
    realizing that even x.509 identity certificates with enormous amounts
    of personal information were also a significiant privacy threat.
    so you saw some retrenchment to "relying-party-only" certificates
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    which basically only contained some type of account number and a
    public key ... where all the personal information was kept by the
    institution in the account record ... and not generally available.
    however, it is trivial to demonstrated that such relying-party-only
    certificates are redundant and superfluous ... if you ahve to access
    the account record (which might only contains trivial amounts of
    personal information ... like a userid's permissions or some such
    thing).

    the issue in domain name infrastructure ... is that it already
    provides a mapping between a domain name and an ip-address ... and
    that it provides real-time access and distribution of the same
    information. including the public key along with the ip-address
    doesn't increase the exposure. the domain name infrastructure has gone
    thru a spate where the registered email addresses were being harvested
    for spamming purposes ... and eventually got redacted (there also has
    been some recent news articles that possible 1/3rd of information on
    file with at the domain name infrastructure is incorrect ... possibly
    increase the vulnerability to domain name hijacking).

    publishing public keys isn't any more of a threat than blanketing the
    world under digital certificates with the same public keys. it
    isn't as if public keys are shared-secret authentication
    http://www.garlic.com/~lynn/subpubkey.html#secret

    where the same value is used for origination and authentication
    (i.e. divulging a shared secret creates threat of impersonation).
    public keys are purely used for authentication and aren't designed to
    be useable for origination and impersonation.

    recent posting on related aspects
    http://www.garlic.com/~lynn/aadsm22.htm#17 Major Browsers and CAS announce balkenisation of Internet Security

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  7. Re: X.509 and ssh

    Dimitri Maziuk writes:
    > The problems here are opening ldap server to the world, replacing
    > verisign with ldap server's administrator, standardizing use of
    > encryption which may be illegal in some jurisdictions, etfc. Never
    > gonna happen.


    part of this can also be looked at from the security PAIN taxonomy

    P - privacy (sometimes CAIN & confidentiality)
    A - authentication
    I - integrity
    N - non-repudiation

    encryption is frequently associated with P/privacy ... but can also be
    used for integrity (i.e. at least being able to recognize
    modifications in transit).

    digital signatures can also be used as integrity countermeasure to
    modifications as well as being used for A/authentication.

    i've frequently claimed that the vast majority of encryption sessions
    on the internet have been SSL associated with electronic commerce and
    supposedly hiding (encrypting) an account number.

    the threat issue is that leakage of standard account number enables
    fraudulent transactions ... and is frequently lumped with identity
    theft/fraud ... but there has been activity in the past couple years
    attempting to strongly differentiate account fraud from identity fraud
    (although both involve leakage of sensitive information for fraudulent
    purposes).

    the SSL activity around e-commerce and the original payment gateway
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    was supposedly both to authenticate the communicating website and hide
    the account numbers. however, there has been lots of stuff attacking
    the infrastructure at points other than the digital certificate part
    of the operation. part of this might be attributed to certification
    authorty industry embellishing the role of digital certificate as the
    cornerstone of the security process ... as opposed as to one specific
    mechanism that could used to implement one small piece of an
    end-to-end secure business process .. i.e. ignore the digital
    certificate and attack at some less well defended part of the
    infrastructure ... one of my analogies has been installing a specific
    kind of bank vault door in an open field w/o walls, ceilings, floors
    .... and then trying to convince everybody that the only way of getting
    what was behind the door was to attack the vault door.

    now back to the early SSL activity
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    and attempting to hide (encrypt) account numbers during transmission.
    for long before the internet, the major attack on account numbers has
    been harvesting point-of-sale and/or backroom repositories (that
    needed the account numbers for other parts of the business process)
    .... frequently (some 70percent) by insiders. The encryption during
    transmissioin was just to not create additional avenues for harvesting
    account numbers. however, it ignored that havesting the backroom
    repositories (that were in use by several backroom business process)
    was still the major threat ... and just the fact that there was
    internet connectivity created numerous additional threat avenues for
    the major vulnerability (that the SSL encryption did nothing to
    address) related to repository harvesting.
    http://www.garlic.com/~lynn/subpubkey.html#harvest

    that gave rise to my observation that even if you buried the world
    under miles of encryption (and digital certificates), it wasn't going
    to address account number leakage and account fraud.
    http://www.garlic.com/~lynn/subpubkey.html#fraud

    what x9.59 financial standard ... mentioned in the previous post
    http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh

    tried to do was to also eliminate account number leakage as a
    vulnerability ... rather than trying to use constantly increasing
    amounts of encryption in an attempt to prevent account number leakage
    .... change the paradigm and create an environment where a leaked
    account number is no longer threat/vulnerability for fraudulent
    transactions.

    one of the issues in the mid-90s was that there were some PKI-oriented
    financial transaction protocol definitions; they would use a digital
    signature for authentication/integrity along with an appended
    relying-party-only digital certificate. however, they failed to create
    a business rule that made account numbers used in digitally signed
    transactions invalid when used in transactions that weren't digitally
    signed. this met that account number leakage still presented a serious
    account fraud threat and so also required that the account number
    continue to be encrypted (in addition to using it in a digitally
    signed transaction) ... aka this is the scenario where encryption
    has to be used for things like shared-secrets
    http://www.garlic.com/~lynn/subpubkey.html#secret

    where divulging the information can result in fraud. the claim is if
    you change the paradigm and the items can no longer be used
    fraudulently, then the need for encryption is drastically reduced
    (similarly encryption isn't the only solution if only integrity needs
    to be addressed).

    the other part was that since it was a relying-party-only certificate,
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    the whole thing still had to be sent to the responsible financial
    institution that was responsible for the certificate (and the
    account). the financial institution pulled the account number from the
    transaction and retrieved the account record ... which had all the
    financial information as well as the originally registered public
    key. the financial institution then validated the digital signature
    with the public key in the account record. as a result the attached
    digital certificate was totally redundant and superfluous.

    it is actually slightly worse than totally redundant and superfluous.
    the typical retail financial transaction size is on the order of 60-80
    bytes and the mid-90s attached, relying-party-only certificate
    overhead ran 4k to 12k bytes. not only was attaching the
    relying-party-only digital certificate redundant and superfluous, it
    also resulted in payload bloat of two orders of magnitude (100 times).

    somewhat in response, the x9 financial standards group did start a
    work item for compressed certificates ... hoping to get the size down
    to on the order of 300 bytes (so it is only a five times payload bloat
    instead of 100 times payload bloat for unnecessary, redundant and
    superfluous certificates). one of the approaches was to establish that
    all fields that were common to the relying-party-only certificates
    could be eliminated (leaving only fields that were unique to a
    specific digital certificate) on the assumption that the relying party
    already had copies of all the common fields. I pointed out that if you
    eliminated all digital certificate fields that the relying-party
    already had copies of, digital certificates could be reduced to zero
    fields and zero bytes. rather than saying that it was redundant and
    superfluous to attach digital certificates ... it was perfectly valid
    to attach zero-byte, compressed digital certificates.

    note that the original observation is that the domain name
    infrastructure is both

    1) a technology; providing trusted, real-time, online distribution
    of information

    and

    2) a business; providing trusted, real-time, online distribution of
    information related to domain names.

    it turns out that as a business, a public key can also be a perfectly
    valid domain-name-associated piece of information and be distributed
    in real-time (rather than requiring stale, static, redundant and
    superfluous digital certificates to provide an association between a
    domain name and a public key).

    the issue with LDAP isn't so much that real-time, online distribution
    of information isn't a valid implementation design (one can point to
    search engines in addition to the domain name infrastructure as
    another example of real-time, online information distribution
    mechanism) ... it is just that LDAP designers possibly didn't give a
    lot of thot in the protocol to attacks, threats, vulnerabilities, and
    countermeasures.

    for instance, it is possible for both LDAP and RADIUS to have
    authentication, authorization, and account information in a backend
    RDBMS database ... potentially a LDAP and a RADIUS deployment could
    even share the same backend RDBMS database. There are RADIUS
    implementation, deployments that support digital signature
    verficiation as authentication mechanism
    http://www.garlic.com/~lynn/subpubkey.html#radius

    where the public key used to verify the digital signature is onfile in
    the backend database (in lieu of current common deployments that used
    RADIUS shared-secret, password mechanisms, where the shared-secret is
    in the backend database).

    I would assert that the problem isn't in the actual backend database
    that might be used by LDAP (many deployments is frequently some RDBMS)
    .... since there are examples of RADIUS protocol being able to utilize
    essentially the same backend database.

    Furthermore, domain name infrastructure protocol isn't tied to a
    specific backend database implementation ... I would assert that it is
    equally possible to create a domain name infrastructure deployment
    that used a backend RDBMS database in similar ways to the way that
    many LDAP deployments make use of backend RDBMS database.

    and to complete the topic drift ... lots of posts about the
    original relational/sql project
    http://www.garlic.com/~lynn/subtopic.html#systemr

  8. Re: X.509 and ssh

    Anne & Lynn Wheeler sez:
    > Dimitri Maziuk writes:
    >> Add DS record (like MX, for ldap directory server) to DNS. Include
    >> host keys in host's ldap record.
    >>
    >> We could do SPF the same way, too.
    >>
    >> The problems here are opening ldap server to the world, replacing
    >> verisign with ldap server's administrator, standardizing use of
    >> encryption which may be illegal in some jurisdictions, etfc.
    >> Never gonna happen.

    >
    > you don't need to do encryption ... all you need to do is public key
    > and digital signature as part of authentication.


    Yeah, well... The question is not whether it's ok to send an rsa
    host key to someone who may not be an Al Qaeda member, it's who
    gets to spend the next 10 years and every penny he can borrow,
    beg, and steal in court sessions trying to figure that one out.
    If that's sysadmin in charge of ldap server, you can be plenty
    sure he's simply not going there.

    The other thing is, currently it is up to the client to set up
    ssh and known_hosts file -- whatever they do it's their problem.
    If the scheme utilizing crypto key/signature authentication
    becomes the Internet standard, the implied requirment here is
    client-side installation of crypto software. Apparently in e.g.
    Freedom that means getting a government license and giving them
    the keys. Dunno what they do about https over there. Given the
    U.S. government views on eavesdropping I'm a little surprised
    they haven't tried to regulate rfc 2818 already.

    > the issue in domain name infrastructure ... is that it already
    > provides a mapping between a domain name and an ip-address ... and
    > that it provides real-time access and distribution of the same
    > information. including the public key along with the ip-address
    > doesn't increase the exposure.


    No, the problem is not exposure, it's DNS.

    > (there also has
    > been some recent news articles that possible 1/3rd of information on
    > file with at the domain name infrastructure is incorrect ...


    Exactly. There's also information that's intentionally omitted:
    e.g. my workstation does not have a hostname visible to the Internet,
    yet it's the only machine in our domain that accepts ssh connections
    from the Internet. Add DNS spoofing and domain name hijacking --
    would you really want to build a reliable authentication
    infrastructure on top of that?

    Besides, thanks to DHCP an IP address does not necessarily
    identify a unique computer (whereas a host key should).

    Dima
    --
    Politics and religion are just like software and hardware. They all suck, the
    documentation is provably incorrect, and all the vendors tell lies.
    -- Andrew Dalgleish

  9. Re: X.509 and ssh

    >>>>> "DM" == Dimitri Maziuk writes:

    DM> Add DS record (like MX, for ldap directory server) to DNS. Include
    DM> host keys in host's ldap record.

    DM> We could do SPF the same way, too.

    DM> The problems here are opening ldap server to the world, replacing
    DM> verisign with ldap server's administrator, standardizing use of
    DM> encryption which may be illegal in some jurisdictions, etfc.

    Um... I think the overriding problem is the need for DNSSEC!

    --
    Richard Silverman
    res@qoxp.net


  10. Re: X.509 and ssh

    >>>>> "ALW" == Anne & Lynn Wheeler writes:

    ALW> Dimitri Maziuk writes:
    >> Add DS record (like MX, for ldap directory server) to DNS. Include
    >> host keys in host's ldap record.
    >>
    >> We could do SPF the same way, too.
    >>
    >> The problems here are opening ldap server to the world, replacing
    >> verisign with ldap server's administrator, standardizing use of
    >> encryption which may be illegal in some jurisdictions, etfc. Never
    >> gonna happen.


    ALW> you don't need to do encryption ... all you need to do is public
    ALW> key and digital signature as part of authentication.

    I've been meaning to ask you for a while: is the period key on your
    keyboard stuck?

    --
    Richard Silverman
    res@qoxp.net


  11. Re: X.509 and ssh

    "Richard E. Silverman" writes:
    > I've been meaning to ask you for a while: is the period key on your
    > keyboard stuck?


    there is a stanford phd thesis ... joint with language and computer ai
    from the early 80s on my email, posting, keyboard use, etc
    habits. there was a researcher that sat in the back of my office for 9
    month, s taking notes on how i communicated, went with me to meetings,
    etc. they also got copies of all my incoming & outgoing email, all my
    postings, and logs of all my incoming and outgoing instant messages.
    detailed analysis was done on all my face-to-face, verbal, and
    computer communication (including typing idiosyncrasies).

    besides the phd thesis, the material was also used in subsequent books
    and papers.

    misc. collected postings mentioning commputer mediated communication
    http://www.garlic.com/~lynn/subtopic.html#cmc

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  12. Re: X.509 and ssh

    Definitely reverse engineering is not necessary to be
    compatible/interoperable !


  13. Re: X.509 and ssh

    Dimitri Maziuk writes:
    > Exactly. There's also information that's intentionally omitted:
    > e.g. my workstation does not have a hostname visible to the Internet,
    > yet it's the only machine in our domain that accepts ssh connections
    > from the Internet. Add DNS spoofing and domain name hijacking --
    > would you really want to build a reliable authentication
    > infrastructure on top of that?


    the issue is that the domain name infrastructure is the authoritative
    agency for domain name ownership. the domain name infrastructure is
    the "trust root" for the PKI certification authority domain name SSL
    certificates. the PKI CA has to cross-check that the entity applying
    for a SSL domain name certificates is the entity registered with
    the domain name infrastructure as owning that domain.

    if the domain name infrastructure information is compromised, then it
    puts the whole PKI CA ssl domain name certificates at risk. the issue
    isn't whether to trust the domain name infrastructure ... as opposed
    to trusting a PKI CA ssl domain name certificate .... the issue is
    that the domain name infrastructure is the trust root for all of it
    .... including the PKI CA ssl domain name certificates.

    If the their are integrity issues with the domain name infrastructure,
    then those integrity issues propogate to all PKI CA ssl domain name
    certificates (i.e. a security infrastructure is only as strong as its
    weakest link). integrity issues putting the domain name infrastructure
    at risk ... also put PKI CA ssl domain name certificates at risk ...
    because the domain name infrastructure is the authoritative agency for
    domain name ownership ... and therefor the trust root for all PKI CA
    ssl domain name certificates.

    that is why my oft repeated observation that integrity improvements in
    the domain name infrastructure have been backed by the PKI CA industry
    .... since they are dependent on the integrity of the domain name
    infrastructure (just like everybody else). part of those integrity
    improvements is to have domain name owners register a public key when
    they register the domain name. then all future communication with the
    domain name infrastructure is digital signed as one of the
    countermeasures for domain name hijacking.

    domain name hijacking not only puts everybody directly dependent on
    the domain name infrastructure at risk ... but it also puts the PKI CA
    industry at risk ... because the hijacker can now apply for a SSL
    domain name certificate and get it ... since the hijacker is now
    listed as the owner of the domain.

    that in turn leads to the observation that if the domain name
    infrastructure relies on the digital signature verification (using the
    onfile public key), then so can the CA PKI industry for SSL domain
    name certificate applications (in part because the digital signature
    verification is validating the true owner of the domain name, if this
    is vulnerable ... then you still have domain name hijacking, if you
    can still have domain name hijacking ... then the hijacker can still
    obtain perfectly valid SSL domain name certificate ... i.e. the
    onfile public key is now the trust root for the SSL domain name
    certificates).

    the catch22 is that if the CA PKI industry starts accepting such
    onfile public keys as the trust root for SSL domain name certificates
    (as countermeasure to things like domain name hijacking) ... then why
    can't the rest of the world ... eliminating the PKI CA operators as a
    redundant and superfluous unncessary intermediary.

    recent post also mentioning the "catch-22" dilemma facing the
    CA PKI ssl domain name certificate industry
    http://www.garlic.com/~lynn/aadsm22.htm#22 Major Browsers and CAS announce balkanisation of Internet Security

    the above also contains long list of prior posts examining the
    catch-22 delemma.

    misc. past posts mentioning domain name hijacking
    http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
    http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
    http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
    http://www.garlic.com/~lynn/aadsm10.htm#cfppki20 CFP: PKI research workshop
    http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
    http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
    http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
    http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
    http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
    http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
    http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
    http://www.garlic.com/~lynn/2000e.html#47 Why trust root CAs ?
    http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
    http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
    http://www.garlic.com/~lynn/2001g.html#19 Root certificates
    http://www.garlic.com/~lynn/2001l.html#26 voice encryption box (STU-III for the masses)
    http://www.garlic.com/~lynn/2001n.html#73 A PKI question and an answer
    http://www.garlic.com/~lynn/2004h.html#28 Convince me that SSL certificates are not a big scam
    http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
    http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
    http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
    http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  14. Re: X.509 and ssh

    Richard E. Silverman sez:
    >>>>>> "DM" == Dimitri Maziuk writes:

    >
    > DM> Add DS record (like MX, for ldap directory server) to DNS. Include
    > DM> host keys in host's ldap record.
    >
    > DM> We could do SPF the same way, too.
    >
    > DM> The problems here are opening ldap server to the world, replacing
    > DM> verisign with ldap server's administrator, standardizing use of
    > DM> encryption which may be illegal in some jurisdictions, etfc.
    >
    > Um... I think the overriding problem is the need for DNSSEC!


    Well... it's in my other post, but in reality DNS as it is works for
    large number of users. DNSSEC implementation can be orthogonal to
    the above, it's things like political quagmire that really kill
    such proposals.

    As far as the chain of trust goes, if you've paranoid security
    requrements you'll probably want to obtain the key out of band,
    directly from the issuer, regardless of how many digital
    signatures there are on somebody's DNS, LDAP, SSH, etc. servers.

    OTGH, it is not clear what one would hope to achieve by hijacking
    someone else's ssh server -- about the only thing they can get is
    some poor shmuck's username and password, and said poor shmuck
    will probably immediately contact the admin of the real server
    when he finds out his password no longer works.

    In reality, the amount of work required to set it up is way
    beyond the average skript kiddie's ablility and the return
    is uncertain at best. A professional will probably find an
    easier way in while a skript kiddie will stick to the worms
    -- IOW, the situation we already have.

    Dima
    --
    The speed at which a mistyped command executes is directly proportional
    to the amount of damage done. -- Joe Zeff

  15. Re: X.509 and ssh

    Dimitri Maziuk writes:
    > As far as the chain of trust goes, if you've paranoid security
    > requrements you'll probably want to obtain the key out of band,
    > directly from the issuer, regardless of how many digital
    > signatures there are on somebody's DNS, LDAP, SSH, etc. servers.


    issuer? is that issuer of digital certificate? or issuer of
    public key? or issuer of something else?

    nominally somebody is the key owner ... except in scenarios like key
    recovery ... where an institution issues both the private and public
    key to the individual.

    there is the authoritative agency for some piece of information ...
    like the domain name infrastructure is the authoritative agency
    for domain name ownership.

    certification authorities ... typically are business processes that
    certify some information ... for situation where the relying parties
    don't directly have the information themselves and lack any means of
    directly contacting any authoritative agency responsible for the
    information.

    finally, certification authorities might manufacture certificates ...
    as a representation of the certification business process. this is for
    environments where the relying parties are dependent on the
    certification process (as in above where they don't directly have the
    information themselves and/or have access to the authoritative agency
    responsible for the information). this certificate/license/credential
    paradigm has served the offline world for centuries. however, the
    certificate/license/credential paradigm is rapidly becoming obsolete
    as the world moves to online ... and relying parties are given direct
    access to the authoritative agencies responsible for the information
    and/or direct access to certification authorities.

    some of the certificate/license/credential operations have attempted
    to find market niches in no-value operations ... where the
    infrastructure can't justify the expense of direct online operations
    for relying parties. however, even this, no-value market niche is
    rapidly shrinking as the cost of performing online operations rapidly
    declines.

    one of the situations is that the domain name infrastructure is the
    authoritative agency for domain name ownership and relying parties are
    all, already doing online operations with the domain name
    infrastructure (it would be straight-forward to piggy-back additional
    information along with the current online information flow).

    part of the issue that somewhat obfuscates the fact that the trust
    root for SSL domain name digital certificates is the domain name
    infrastructure is some of the misdirection about any cryptographic
    integrity of the digital certificates ... which is almost a minor nit
    in the overall end-to-end business operations of the authoritative
    agencies (aka domain name infrastructure) maintaining correct and
    accurate information ... and the certification business operations
    performed by certification authorities ... independent of the actual
    manufacture of the actual digital certificates.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  16. Re: X.509 and ssh

    Anne & Lynn Wheeler sez:
    > Dimitri Maziuk writes:
    >> As far as the chain of trust goes, if you've paranoid security
    >> requrements you'll probably want to obtain the key out of band,
    >> directly from the issuer, regardless of how many digital
    >> signatures there are on somebody's DNS, LDAP, SSH, etc. servers.

    >
    > issuer? is that issuer of digital certificate? or issuer of
    > public key? or issuer of something else?


    Doesn't matter whether it's a digital certificate, public key,
    or a good old unix password. If you don't trust transmission
    channels and you don't trust third parties you go personally
    visit the guy and write it -- whatever it is -- down on a piece
    of paper (to make sure the medium is virus-free). "Elements"
    cigarette paper -- it burns leaving virtually no ash for CSIs
    to recover.
    See also "paranoid".

    Dima
    --
    The most horrifying thing about Unix is that, no matter how many times you hit
    yourself over the head with it, you never quite manage to lose consciousness.
    It just goes on and on. -- Patrick Sobalvarro

  17. Re: X.509 and ssh

    >>>>> "ALW" == Anne & Lynn Wheeler writes:

    ALW> "Richard E. Silverman" writes:
    >> I've been meaning to ask you for a while: is the period key on your
    >> keyboard stuck?


    ALW> there is a stanford phd thesis ... joint with language and
    ALW> computer ai from the early 80s on my email, posting, keyboard
    ALW> use, etc habits. there was a researcher that sat in the back of
    ALW> my office for 9 month, s taking notes on how i communicated, went
    ALW> with me to meetings, etc. they also got copies of all my incoming
    ALW> & outgoing email, all my postings, and logs of all my incoming
    ALW> and outgoing instant messages. detailed analysis was done on all
    ALW> my face-to-face, verbal, and computer communication (including
    ALW> typing idiosyncrasies).

    ALW> besides the phd thesis, the material was also used in subsequent
    ALW> books and papers.

    ALW> misc. collected postings mentioning commputer mediated
    ALW> communication http://www.garlic.com/~lynn/subtopic.html#cmc

    ALW> -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

    I was actually wondering why you constantly post rambling, multi-page
    crypto-stream-of-consciousness, punctuated with pathetic ellipses where
    you couldn't be bothered to actually complete a sentence.

    But, this response is utterly priceless in its cluelessness, so thanks
    anyway.

    --
    Richard Silverman
    res@qoxp.net


  18. Re: X.509 and ssh

    "Richard E. Silverman" writes:
    > I was actually wondering why you constantly post rambling, multi-page
    > crypto-stream-of-consciousness, punctuated with pathetic ellipses where
    > you couldn't be bothered to actually complete a sentence.
    >
    > But, this response is utterly priceless in its cluelessness, so thanks
    > anyway.


    ref:
    http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh

    the referenced phd thesis analyzes my computer communications in
    several hundred pages ... lot more detail than i could ever supply ...
    if you are truely interested.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  19. Re: X.509 and ssh

    Anne & Lynn Wheeler wrote:
    > "Richard E. Silverman" writes:
    >> I was actually wondering why you constantly post rambling, multi-page
    >> crypto-stream-of-consciousness, punctuated with pathetic ellipses
    >> where you couldn't be bothered to actually complete a sentence.
    >>
    >> But, this response is utterly priceless in its cluelessness, so
    >> thanks anyway.

    >
    > ref:
    > http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
    >
    > the referenced phd thesis analyzes my computer communications in
    > several hundred pages ... lot more detail than i could ever supply ...
    > if you are truely interested.


    Which doesn't explain why you ramble or fail to use periods correctly, and
    the capital keys seem to be missing from your keyboard. It helps destroy any
    content in what you're writing.

    May I suggest that you that you examine and take to heart a copy of
    Strunk's"Elements of Style"? It would help your work be more legible.



  20. Re: X.509 and ssh

    "Nico Kadel-Garcia" writes:
    > Which doesn't explain why you ramble or fail to use periods correctly, and
    > the capital keys seem to be missing from your keyboard. It helps destroy any
    > content in what you're writing.
    >
    > May I suggest that you that you examine and take to heart a copy of
    > Strunk's"Elements of Style"? It would help your work be more legible.


    the thesis goes into all of those style issues in some detail ... in
    addition to providing linquistic analysis of the styles ... if you are
    really interested ... read the thesis.

    i spent a couple years with senior publication editor in san jose
    doing that sort of stuff for technical publications; turns out to be a
    different mode/style of operation ... some of it was also during the
    period that the material was being gathered for the phd research
    .... so some of those issues are also examined in some detail in the
    thesis.

    ref:
    http://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
    http://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast