REVIEW: "Biometrics for Network Security", Paul Reid

Discussion in 'Computer Security' started by Rob Slade, doting grandpa of Ryan and Trevor, Oct 1, 2004.

  1. BKBIOMNS.RVW 20040527

    "Biometrics for Network Security", Paul Reid, 2004, 0-13-101549-4,
    U$44.99/C$67.99
    %A Paul Reid
    %C One Lake St., Upper Saddle River, NJ 07458
    %D 2004
    %G 0-13-101549-4
    %I Prentice Hall
    %O U$44.99/C$67.99 +1-201-236-7139 fax: +1-201-236-7131
    %O http://www.amazon.com/exec/obidos/ASIN/0131015494/robsladesinterne
    http://www.amazon.co.uk/exec/obidos/ASIN/0131015494/robsladesinte-21
    %O http://www.amazon.ca/exec/obidos/ASIN/0131015494/robsladesin03-20
    %P 252 p.
    %T "Biometrics for Network Security"

    In the preface, Reid presents biometrics as the cure for all network
    security ills. Given his employment, with a company that sells
    biometric systems, this enthusiasm is understandable, if not totally
    compelling.

    Part one deals with introduction and background. Chapter one is the
    introduction--mostly to the book. The definition of biometrics itself
    is very terse. Authentication technologies are promised in chapter
    two--which starts out by repeating the all-too-common error of
    confusing authentication with identification. Reid then pooh-poohs
    passwords and tokens and praises biometrics as strong authentication,
    without dealing with the fact that a biometric is the ultimate static
    password, or addressing the technologies (and associated error rates)
    needed to make biometrics a viable authentication factor. Privacy is
    confused with intellectual property, access control, and improper
    employee monitoring in chapter three.

    Part two lists biometric technologies. Chapter four is a disorganized
    amalgam of factors generally involved in biometric use and
    applications. Fingerprint features are reviewed in chapter five with
    incomprehensible explanations and unclear illustrations. Attacks
    against fingerprint technologies and systems are raised--but are
    usually dismissed in a fairly cavalier manner. Similar examinations
    are made of face (chapter six), voice (seven), and iris (eight)
    systems.

    Part three looks at implementing the technologies for network
    applications. Chapter nine compares the four biometrics from part
    two, in general terms, and states measures that are rather at odds
    with other biometric literature. Reid makes a big deal out of simple
    error rate metrics in chapter ten. Most of chapter eleven talks about
    hardening biometric devices and hardware. Unconvincing fictional
    "straw man" case studies and some general project planning topics are
    in chapter twelve, with more of the same in thirteen and fourteen.

    Part five, which is only chapter fifteen, casts a rosy-spectacled look
    at the future when all of security will be made perfect through the
    use of biometrics--essentially returning us to the preface.

    Basically, this appears to be a promotional pamphlet padded out to
    book length: it isn't even as good as Richards' article in the
    "Information Security Management Handbook" (cf. BKINSCMH.RVW). The
    material will not help you with a realistic assessment of what
    biometrics can (and cannot) do, or how to implement it. The
    "Biometrics" text by Woodward, Orlans and Higgins (cf. BKBIOMTC.RVW)
    is far superior.

    copyright Robert M. Slade, 2004 BKBIOMNS.RVW 20040527

    --
    ======================

    ============= for back issues:
    [Base URL] site http://victoria.tc.ca/techrev/
    or mirror http://sun.soci.niu.edu/~rslade/
    CISSP refs: [Base URL]mnbksccd.htm
    Security Dict.: [Base URL]secgloss.htm
    Book reviews: [Base URL]mnbk.htm
    Review mailing list: send mail to
    or
     
    Rob Slade, doting grandpa of Ryan and Trevor, Oct 1, 2004
    #1
    1. Advertising

  2. (Rob Slade, doting grandpa of Ryan and Trevor) writes:

    > BKBIOMNS.RVW 20040527
    >
    > "Biometrics for Network Security", Paul Reid, 2004, 0-13-101549-4,



    How does he prevent replay attacks?

    Some use smartcard technology with match-on-card software.

    --
    Sending unsolicited commercial e-mail to this account incurs a fee of
    $500 per message, and acknowledges the legality of this contract.
     
    Bruce Barnett, Oct 2, 2004
    #2
    1. Advertising

  3. "Bruce Barnett" <> wrote in message
    news:cjl7cl$mbc$1$...
    > (Rob Slade, doting grandpa of Ryan and Trevor) writes:
    >
    > > BKBIOMNS.RVW 20040527
    > >
    > > "Biometrics for Network Security", Paul Reid, 2004, 0-13-101549-4,

    >
    >
    > How does he prevent replay attacks?
    >
    > Some use smartcard technology with match-on-card software.


    I suppose one method of securing the biometric authentication from replay
    attacks, is to build into the biometric reader itself one time session IDs.
    A person puts their thumb on the reader, which then generates an ID that is
    used to encrypt the biometric data (and the ID itself). The data is
    decrypted at the server along with the ID (using the server side's expected
    ID), the ID is matched up in the database to confirm validity of the
    biometric data. Then the biometric is matched up, and the person is
    authenticated.

    That should prevent any kind of replay attack, and streamline the process
    without the need of an additional smart card.

    >
    > --
    > Sending unsolicited commercial e-mail to this account incurs a fee of
    > $500 per message, and acknowledges the legality of this contract.


    Ever made any money from this? ;-)

    --
    Richard S. Westmoreland
    http://www.antisource.com
     
    Richard S. Westmoreland, Oct 4, 2004
    #3
  4. "Richard S. Westmoreland" <> writes:

    I was asking about the author's opinion, because this should be an
    indication of his bias and thoroughness to a topic. I'm not a
    biometric expert, but biomterics can't solve every problemn in
    isolation. An unbiased writer would cover these issues. But the
    world is filled with people who think their technology will solve
    every problem in the world.

    > That should prevent any kind of replay attack, and streamline the process
    > without the need of an additional smart card.


    Well, how does one know the reader is trusted? I can walk up to a
    Trojan'ed reader, and it can capture my thumbprint and replay it at a
    later date.


    >The data is
    >decrypted at the server along with the ID (using the server side's expected
    >ID), the ID is matched up in the database to confirm validity of the
    >biometric data.



    This also requires the reader to be connected to the server in order
    to be authenticated. If the network is down, or disconnected, the
    person cannot be authenticated. So that's two potential problems.


    I'm not trying to pick a fight. I was interested in the book, and I
    wanted to see how well he covers the issues. For instance, biometrics
    is just one of three factors that can be used for authentication
    (something you know, something you have, and someone you are). And if
    only biometrics is used, then this isn't always adequate. Bruce
    Schneier made some good comments about the problems of using
    biometrics for authentication.

    Two of the points he covers (my web proxy is down. Otherwise I'd give
    you a reference) are:

    Biometrics is PUBLIC information
    Biometrics cannot be changed.

    Once the fingerprint template is captured, it can be replayed. It's
    not secret information. You can't revoke it and re-issue it to the end
    user.

    Smartcards aren't the best solution to every problem, because they
    cost more than thumbs. :)-)

    But when combined with biometrics, they provide stronger authentication.

    The way I understand it, you can do biometrics/smarcards in at least
    three general categories.

    1) The template is stored on the server.

    Advantage: No smartcard or token is needed
    Problem: Replay attacks, and inability to authenticate if disconnected

    2) Template-On-Card

    Advantage: The template is fetched from the card, not the
    server. So the authentication can be done
    off-line.

    Problem: a smartcard is needed with enough memory to store the
    template Also - there is a danger of a replay attack

    3) Match-on-Card - The algorithm to match the template is on the card,
    as well as the template. Once this is done, the data in the card
    can be unlocked, and the private key on the card can be used to
    authenticate the individual. Usually the card will lock itself up
    if too many bad attempts are made.

    Problem: Getting the algorithm to work on a smartcard (cpu,
    code size, etc.) Some companies tell me they do it, or are
    planning to do it.

    Advantage: Strong authentication, and inability to replay the
    authentication sequence because the private key isn't known or
    revealed - ever.

    Smartcard also have problems. The software I am using doesn't
    authenticate the reader. So the PIN can be stolen, and if the card is
    then stolen, you are out of luck.

    Another approach is the Sony Puppy - which as I understand it combines
    a smartcard and thumbprint reader into one device. You take it with
    you to authenticate yourself.


    This Match-on-Card is what I believe the US Government want to use
    with their Common Access Card. It only makes sense.

    Are you telling me that these issues aren't covered in the book you
    reviewed? Oh well.



    >> --
    >> Sending unsolicited commercial e-mail to this account incurs a fee of
    >> $500 per message, and acknowledges the legality of this contract.

    >
    > Ever made any money from this? ;-)


    Well, I feel better. Others have made money, with the right legal
    threats. It also shuts up the dimwit harvesters when I point out that
    each of my e-mail addresses is unique, and ALWAYS tagged with this
    message. The flames to my ISP quickly die when they realize I did not
    grant them permission to harvest my address, and that I didn't
    "opt-in".


    --
    Sending unsolicited commercial e-mail to this account incurs a fee of
    $500 per message, and acknowledges the legality of this contract.
     
    Bruce Barnett, Oct 4, 2004
    #4
  5. "Bruce Barnett" <> wrote in message
    news:cjscvg$qqm$0$...
    > "Richard S. Westmoreland" <> writes:
    >
    > I was asking about the author's opinion, because this should be an
    > indication of his bias and thoroughness to a topic. I'm not a
    > biometric expert, but biomterics can't solve every problemn in
    > isolation. An unbiased writer would cover these issues. But the
    > world is filled with people who think their technology will solve
    > every problem in the world.


    Sorry I was going off on a tangent - I don't care so much about the book
    itself, thought I'd hop into a conversation about biometrics.

    >
    > > That should prevent any kind of replay attack, and streamline the

    process
    > > without the need of an additional smart card.

    >
    > Well, how does one know the reader is trusted? I can walk up to a
    > Trojan'ed reader, and it can capture my thumbprint and replay it at a
    > later date.


    I considered this. Some kind of CRC the reader goes through and the server
    matches up a hash with the reader's internal circuitry, to confirm it is
    untainted.

    >
    >
    > >The data is
    > >decrypted at the server along with the ID (using the server side's

    expected
    > >ID), the ID is matched up in the database to confirm validity of the
    > >biometric data.

    >
    >
    > This also requires the reader to be connected to the server in order
    > to be authenticated. If the network is down, or disconnected, the
    > person cannot be authenticated. So that's two potential problems.


    Server or desktop/laptop - can be connected to either. If I have an RSA
    SecureID, and the server is down, I'm not getting on then either. I thought
    the point was authentication to the *network*? No network, then I sit and
    wait until it's fixed.

    Rick
     
    Richard S. Westmoreland, Oct 4, 2004
    #5
  6. "Richard S. Westmoreland" <> writes:

    > Sorry I was going off on a tangent - I don't care so much about the book
    > itself, thought I'd hop into a conversation about biometrics.


    No problem.

    >> Well, how does one know the reader is trusted? I can walk up to a
    >> Trojan'ed reader, and it can capture my thumbprint and replay it at a
    >> later date.

    >
    > I considered this. Some kind of CRC the reader goes through and the server
    > matches up a hash with the reader's internal circuitry, to confirm it is
    > untainted.


    There is still two potential problems that ideally should be addressed.

    1) The reader has been compromised. Any fingerprint it sees is
    stores in a hidden location.

    2) The user uses the wrong thumbprint reader. Or some other
    thumbprint reader at another location. The data is captured.


    Both the end user and the remote system has be consider these risks.

    For instance, suppose the reader was attached to the local
    host/controller by a USB cable. Some evil person might insert a USB
    sniffer in the cable, unknown to the remote system.

    While some locations are going to have high physical
    security, not all locations will. So it's a potential problem.

    I mentioned the Sony Puppy,

    http://bssc.sel.sony.com/Professional/puppy/products.html

    Because this is a way for a remote system to confirm that the local
    system does have the token. Only with the token can the local system
    generate the suitable credentials. The local system cannot replay the
    data, because it doesn't have the private key stored inside the puppy.

    And stealing the token won't help, because only the fingerprint will
    unlock the key/credentials.

    >> This also requires the reader to be connected to the server in order
    >> to be authenticated. If the network is down, or disconnected, the
    >> person cannot be authenticated. So that's two potential problems.

    >
    > Server or desktop/laptop - can be connected to either. If I have an RSA
    > SecureID, and the server is down, I'm not getting on then either.


    Well, a smartcard can be used without a central server. I've been
    using the open source musclecard applet to do so. The java code in the
    card generates a key pair, and exports the private key. The public key
    can be stored in a local machine's cache/storage (especially if the
    user is a frequent user).

    The host generates a random challange, and asks the card to encrypt it
    with the private key. The card does so, and the host verifies the ID
    and grants access. (Once the PIN is verified).

    This has a man-in-the-middle risk, by the way.


    >I thought
    > the point was authentication to the *network*?


    I see the need for both local authentication and remote/network
    authentication.

    In large scale systems, with millions of users (the CAC card has 5
    million cards issued), there is an advantage for allowing the local
    system to authenticate a user, expecially in remote locations
    throughout the world, during war time, etc..


    > No network, then I sit and
    > wait until it's fixed.


    There are critical situations where waiting is not suitable. Medical,
    homeland security, first response teams, military, etc.



    Cheers.

    --
    Sending unsolicited commercial e-mail to this account incurs a fee of
    $500 per message, and acknowledges the legality of this contract.
     
    Bruce Barnett, Oct 5, 2004
    #6
  7. Bruce Barnett <> writes:
    > Well, a smartcard can be used without a central server. I've been
    > using the open source musclecard applet to do so. The java code in
    > the card generates a key pair, and exports the private key. The
    > public key can be stored in a local machine's cache/storage
    > (especially if the user is a frequent user).
    >
    > The host generates a random challange, and asks the card to encrypt
    > it with the private key. The card does so, and the host verifies the
    > ID and grants access. (Once the PIN is verified).


    in general private key encryption ... as in some form of digital
    signature ... whether of a challenge of some other form of data
    .... tends to either be "something you know" or "something you have"
    authentication, aka from 3-factor authentication

    * something you know
    * something you have
    * something you are

    the correpsonding public key is registered with the relying party
    (central authority, your local pc, etc) and the key-owner keeps the
    private key in an encrypted software file or in a hardware token.

    if the convention has the key-owner keeping the private key in an
    encrypted file (say like some of the pkcs12 or other browser
    conventions) ... then the relying party when it sees a valid digital
    signature ... can assume that the key-owner had supplied the correct
    pin to decrypt the software file in order that the digital signature
    be performed.

    the private key can be kept in a hardware token, and when a relying
    party sees a valid digital signature, they can assume "something you
    have" authentication on behalf of the key owner.

    there are some hardware tokens that are constructed so that the
    private key operations (encryption and/or digital signature) are only
    performed when the correct PIN and/or biometric is presented
    .... i.e. two factor authentication

    * something you have
    * something you know (pin) or something you are (biometric)

    it is possible to construct a hardware token where three factor
    authentication might be assumed ... where both a PIN and the correct
    biometric is required for the token to do its job. then the relying
    party might presume three factor authentication

    * something you know (pin/password)
    * something you have (hardware token)
    * something you are (biometric)

    in this case, the relying party (central authority, your local pc,
    kerberos and/or radius service, etc) could reansonably expect to have

    1) the public key registered,
    2) the integrity characteristics of the public key registered,
    3) the hardware integrity characteristics of the hardware token registered
    4) the operational integrity characteristics of the hardware token
    registered

    so that when the relying party sees a digital signature for
    verification, it has some reasonable level of assurance as to what the
    verification of such a digital signature might mean (and how much it
    might trust such a digital signature as having any meaning).

    for a relying party to get a digital signature and be able to verify
    that the digital signature is correct .... w/o additional information
    the relying party has absolutely no idea as to the degree or level of
    trust/assurance such a digital signature means.

    somewhat orthogonal and has frequently thoroughly obfuscated the
    issues about the level of trust/assurance that a relying-party might
    place in a digital signature are digital certificates.

    digital certificates were originally invented for the early '80s
    offline email environment. the recipient (aka relying party) gets a
    piece of email and has no way of proving who the sender was. so the
    idea was to have the sender digitally sign the email. if the sender
    and recipient were known to each other and/or had previous
    interaction, the recipient could have the sender's public key on file
    for validating the digital signature.
    http://www.garlic.com/~lynn/subpubkey.html#certless

    however, there was a theoritical offline email environment from the
    early '80s where the sender and the recipient had absolutely no prior
    interactions and the desire was to have the email be processed w/o
    resorting to any additional interactions. this led to the idea of 3rd
    party certification authorities who would certify as to the senders
    identity. the sender could create a message, digital sign it and send
    off the message, the digital signature and the 3rd party certified
    credential (digital certificate). the recipient eventually downloads
    the email, hangs up, and has absolutely no recourse to any additional
    information (other than what is contained in the email).

    by the early '90s, this had evolved into the x.509 identity (digital)
    certificate. however, during the mid-90s, this became serverely
    depreciated because of the realization about the enormous liability
    and privacy issues with arbritrarily spewing x.509 identity
    certificates all over the world. there was some work on something
    called an abbreviated relying-party-only digital certificate ... that
    basically contained only a public key and some form of account
    number. random past relying-party-only posts:
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    the relying party would use the account to look-up in some sort of
    repository the actual information about the sender ... as opposed to
    having the liability and privacy issues of having the sender's
    information actually resident in the certificate. however, in the PGP
    model as well as all of the existing password-based authentication
    schemes ... it was possible to show that whatever respository contains
    information about the sender ... could also contain the actual
    sender's public key. In the widely deployed password-based schemes
    like RADIUS, Kerberos, PAM, etc ... just substitute the registration
    of a password and permissions with the registration of a public key
    and permissions. So it was trivial to show that for all of the
    replying-party-only certificate scenarios that the actual certificate
    was redundant and superfluous.

    of course, the other issue with the original design point for digital
    certificates of the early '80s offline email paradigm where a sender
    and a recipient that had absolutely no prior interaction and the
    recipient had absolutely no other recourse for obtaining information
    about the sender .... had pretty much started to disappear by the
    early 90s.

    and of course, the issue of certificates being redundant and superfluous
    and possibly representing severe liability and privacy issues ... the
    certificates didn't actually contribute to telling the recipient
    (or relying party) to what degree that they could actually trust
    a possible digital signature aka the issue of what the relying party
    can infer from validating a digital signature .... does it represent
    anything from three factor authentication

    * something you know
    * something you have
    * something you are

    and say if it might actually be associated with something you have
    hardware token .... what level of assurance is associated with a
    specific hardware token.

    the issue in which a possible digital signature (or other private key
    operation) is performed .... like biometric sensor inferface and/or
    hardware token pin/password interface ... is also of some possible
    concern to a recipient or relying party. one of the scenarios for
    FINREAD terminal is to possibly have the terminal also digitally sign
    transactions .... so the relying party has some additional idea
    about the level of trust that they can place in what they have recieved.
    (not only was a certified FINREAD terminal used, but the transaction
    carries the digital signature of the FINREAD terminal).

    misc. past FINREAD terminal posts
    http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
    http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
    http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
    http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
    http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
    http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
    http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
    http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
    http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
    http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
    http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
    http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
    http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
    http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
    http://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
    http://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
    http://www.garlic.com/~lynn/aadsm16.htm#9 example: secure computing kernel needed
    http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
    http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
    http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
    http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
    http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
    http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
    http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
    http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
    http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
    http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
    http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
    http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
    http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
    http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
    http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
    http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
    http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
    http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
    http://www.garlic.com/~lynn/2002g.html#69 Digital signature
    http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
    http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
    http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
    http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
    http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
    http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
    http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
    http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
    http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
    http://www.garlic.com/~lynn/2003o.html#44 Biometrics
    http://www.garlic.com/~lynn/2004.html#29 passwords
    http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
    http://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
    http://www.garlic.com/~lynn/2004j.html#1 New Method for Authenticated Public Key Exchange without Digital Certificates

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
     
    Anne & Lynn Wheeler, Oct 5, 2004
    #7
  8. followup
    http://www.garlic.com/~lynn/2004l.html#4

    note that while three factor authentication

    * something you know
    * something you have
    * something you are

    allows pin/passwords as "something you know" authentication, there can
    be a big different between "something you know" as a "shared secret"
    and "something you know" as a "non-shared secret".

    for instance the current payment card scenario effectively has account
    numbers as shared-secrets ... since gaining knowledge of the account
    number can enable fraudulent transactions. harvesting of merchant
    transaction files can result in account/identity theft impact because
    of the ability to use the account numbers for fraudulent transactions.
    some related discussion of security proporitional to risk
    http://www.garlic.com/~lynn/2001h.html#61
    misc. past postings about secrets and account numbers
    http://www.garlic.com/~lynn/subpubkey.html#secrets

    where there is a big focus on protected all occurances of account number
    because of its shared-secret vulnerability. an alternative solution is
    x9.59
    http://www.garlic.com/~lynn/index.html#x959

    where financial transactions are digitally signed and there is a
    business rule that account numbers used in x9.59 transactions can't be
    used in non-authenticated transactions. as a result, just knowing an
    account number used in an x9.59 doesn't enable fraudulent transactions
    (or account/identity theft) and therefor such account numbers no
    longer needs to be considered as a shared-secret.

    one of the requirements of shared-secret based infrastructure (in
    addition to the requirement to needing to protect the shared-secret)
    is frequently to require a unique shared-secret for different security
    domains .... aka ... the password on file with your local garage ISP
    should be different than passwords used for personal banking or for
    you job. The issue is that for different security domains ... they may
    have different levels of protection for shared-secrets. there may also
    be instances where one security domain may be at odds with some other
    security domain.

    In effect, anything that is on file in a security domain ... and just
    requires reproducing the same value for authentication can be
    considered a shared secret. shared-secret passwords frequently also
    have guidelines regarding frequently changes for the shared-secret.
    some past references to password changing rules:
    http://www.garlic.com/~lynn/2001d.html#52
    http://www.garlic.com/~lynn/2001d.html#53
    http://www.garlic.com/~lynn/2001d.html#62

    A "something you have" hardware token can also implement "something
    you know" two-factor authentication, where the "something you know" is
    a non-shared-secret. The hardware token contains the secret and is
    certified to require the correct secret entered for correct operation.
    Since the secret isn't shared ... and/or on file with some security
    domain, it is a non-shared-secret ... rather than a shared-secret.

    A relying party needs some proof (possibly at registration) that
    authentication information (like a digital signature) is uniquely
    associated with a specific hardware token and furthermore needs
    certified proof that a particular hardware token only operates in a
    specific way when the correct password has been entered .... to
    establish trust for the relying party that two-factor authentication
    is actually taking place. In the digital signature scenario, based on
    certificate of the hardware token, the relying party when it validates
    a correct digital signature then can infer two-factor authentication:

    * something you now (password entered into hardware token)
    * something you have (hardware token generated digital signature)

    In a traditional shared-secret scenario, if a shared-secret has been
    compromised (say merchant transaction file has been harvested), new
    shared-secrets can be issued. Typically, there a much fewer
    vulnerabilities and different threat models for non-shared-secret
    based infrastructures compared to shared-secret based infrastructures
    (in part because of possible greater proliferation of location of
    shared-secrets).

    It turns out that "something you are" biometrics can also be
    implemented as either a shared-secret infrastructure or a
    non-shared-secret infrastructure. Biometrics typically is implemented
    as some sort of mathematical value that represents some biometric
    reading. In a shared-secret scenario, this biometric mathematical
    value is on file someplace, in much the same manner that a password
    might be on file. The person is expected to reproduce the biometric
    value (in much the same way they might be expected to reproduce the
    correct password). Depending on the integrity of the environment that
    is used to convert the biometric reading to a mathematical value
    .... and the integrity of the environment that communicates the
    biometric value, a biometric shared-secret imfrastructure may be prone
    to identical vulnerabilities as shared-secret password systems ... aka
    somebody havests the biometric value(s) and is able to inject such
    values in to the authentication infrastructure to spoof an individual.

    Many shared-secret biometric infrastructures with distributed sensors
    that might not always be under armed guards ... frequently go to a
    great deal of trouble specifying protection mechanisms for personal
    biometric information. One of the issues with respect to shared-secret
    biometric infrastructures compared to shared-secret password
    infrastructures, in that it is a lot easier to replace a password than
    say an iris or a thumb.

    There are also hardware tokens that implement non-shared-secret
    biometrics, in much the same way that non-shared-secret passwords are
    implemented. Rather than having the biometric values on file at some
    repository, the biometric value is contained in a personal hardware
    token. The personal hardware token is certified as performing in a
    specific manner only when the correct biometric value is entered.
    Given adequate assurance about the operation of a specific hardware
    token, a relying party may then infer from something like validating
    a digital signature that two-factor authentication has taken place,
    i.e.

    * something you have (hardware token that uniquely generates signature)
    * something you are (hardware token requiring biometric value)

    biometric values are actually more complex than simple passwords,
    tending to having very fuzzy matches. for instance an 8-character
    password either matches or doesn't match. A biometric value is more
    likely to only approximately match a previously stored value.

    Some biometric systems are frequently designed with hard-coded fuzzy
    match threshhold values .... say like a 50 percent match value. These
    systems frequently talke about false positives (where a 50 percent
    match requirement results in authenticating the wrong person) or false
    negatives (where a 50 percent match requirement results in rejecting
    the correct person). Many of these systems tend to try and adjust
    their fuzzy match value settings in order to minimize both the false
    positives and false negatives.

    in value-based systems, hard-coded fuzzy match values may represent a
    problem. an example is transaction system that supports both $10
    transactions and million dollar transactions. In general, a risk
    manager may want to have a higher match requirement for higher value
    transactions.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
     
    Anne & Lynn Wheeler, Oct 6, 2004
    #8
  9. Rob Slade, doting grandpa of Ryan and Trevor

    Vin McLellan Guest

    Bruce Barnett <> wrote:

    >>>This also requires the reader to be connected to the server in
    >>>order to be authenticated. If the network is down, or disconnected,
    >>>the person cannot be authenticated. So that's two potential
    >>>problems.


    Richard S. Westmoreland <> replied:

    >>Server or desktop/laptop - can be connected to either. If I have
    >>an RSA SecureID, and the server is down, I'm not getting on then
    >>either. I thought the point was authentication to the *network*?
    >>No network, then I sit and wait until it's fixed.


    Actually, at least so far as RSA's SecurID, this is no longer true.

    Working with Microsoft, RSA developed a new SecurID for Windows
    (SID4Win) infrastructure that not only simplifies the user experience
    by replacing the traditional Window's logon password with a SecurID,
    it requires (and keeps an audit record of) two-factor authentication
    not only at the network perimeter, as is traditional, but also
    whereever corporate data is stored.

    RSA Authentication Agents are now installed *inside* the network, on
    the Windows network domain, and networked XP desktops (even when they
    are temporarily disconnected from the network), and *outside" the
    perimeter, on remote company laptops -- and it works even when they
    too are also temporarily disconnected from the Internet.

    (See RSA's data sheet, white paper, and webcast on SID4Win at:
    <http://www.rsasecurity.com/node.asp?id=1173>.

    As Bruce noted in his second message:

    > I see the need for both local authentication and remote/network
    > authentication.
    >
    >In large scale systems, with millions of users (the CAC card has 5
    >million cards issued), there is an advantage for allowing the local
    >system to authenticate a user, expecially in remote locations
    >throughout the world, during war time, etc..


    Actually, I think the demand is more prosaic. If we extend strong
    authentication and audit logs to the desktop (let along to mobile
    corporate laptops), they can't functionally depend on omnipresent
    network access. Networks simply aren't yet dependable enough that we
    can let network unavailablity stop all work.

    With RSA's SDI4Win infrastructure, PC users temporarily disconnected
    from the network can still use their SecurIDs for local access, and
    laptop users remain free to roam. A corporate laptop user can use his
    SecurID (and memorized PIN) to access his mobile machine in a plane at
    35,000 feet, even without a network connection, because the RSA
    Authentication Manager (what RSA used to call the ACE/Server) stores a
    secure cache of future SecurID token-codes -- for a variable number of
    days (pre-set, per user or group, by the network admin) -- on the
    laptop.

    When the PC or laptop again connects with the enterprise network and
    the RSA Authentication Manager, the laptop's Authentication Agent
    forwards an audit log to the RSA Authentication Manager about what has
    happened in the interim... and replenishes its stored cache of SecurID
    token-codes for future off-line access.

    With the new IT security requirements associated with various external
    regulatory regimes (Basel II, Sarbanes-Oxley, HIPAA, GLBA, etc.), many
    enterprises find it necessary to have audit records and strong access
    controls on all repositories of proprietary or confidential corporate
    data. As necessary, these AAA systems can be buttressed by crypto,
    SSO, and federated access controls, but the operational baseline for
    strong authentication is no longer limited by network access, nor
    limited to perimeter access controls.

    This is new, but since RSA is providing this capability at no
    additional charge to all of the thousands of sites which use the
    current version of the ACE/Server (aka, the RSA Authentication
    Manager), it will probably be widely adopted fairly quickly.

    Back to biometrics:

    Perhaps the most successful use of biometrics I have seen is the use
    of a local biometrics check to block fraudulent multiple claims in
    benefits payments in the social services. In that mode, the benefits
    recipient is first registered on a secure terminal, under supervision.
    A central record is made of the recipient's ID and biometric (a
    fingerprint, as I recall) and his approved benefits, and a check is
    made to make sure that recipient is making no other claims on the
    system under another identity.
     
    Vin McLellan, Oct 7, 2004
    #9
  10. Rob Slade, doting grandpa of Ryan and Trevor

    Vin McLellan Guest

    Bruce Barnett <> wrote:

    >>>This also requires the reader to be connected to the server in
    >>>order to be authenticated. If the network is down, or disconnected,
    >>>the person cannot be authenticated. So that's two potential
    >>>problems.


    Richard S. Westmoreland <> replied:

    >>Server or desktop/laptop - can be connected to either. If I have
    >>an RSA SecureID, and the server is down, I'm not getting on then
    >>either. I thought the point was authentication to the *network*?
    >>No network, then I sit and wait until it's fixed.


    Actually, at least so far as RSA's SecurID, this is no longer true.

    Working with Microsoft, RSA developed a new SecurID for Windows
    (SID4Win) infrastructure that not only simplifies the user experience
    by replacing the traditional Window's logon password with a SecurID,
    it requires (and keeps an audit record of) two-factor authentication
    not only at the network perimeter, as is traditional, but also
    whereever corporate data is stored.

    RSA Authentication Agents are now installed *inside* the network, on
    the Windows network domain, and networked XP desktops (even when they
    are temporarily disconnected from the network), and *outside" the
    perimeter, on remote company laptops -- and it works even when they
    too are also temporarily disconnected from the Internet.

    (See RSA's data sheet, white paper, and webcast on SID4Win at:
    <http://www.rsasecurity.com/node.asp?id=1173>.

    As Bruce noted in his second message:

    > I see the need for both local authentication and remote/network
    > authentication.
    >
    >In large scale systems, with millions of users (the CAC card has 5
    >million cards issued), there is an advantage for allowing the local
    >system to authenticate a user, expecially in remote locations
    >throughout the world, during war time, etc..


    Actually, I think the demand is more prosaic. If we extend strong
    authentication and audit logs to the desktop (let alone to mobile
    corporate laptops), they can't functionally depend on omnipresent
    network access. Networks simply aren't yet dependable enough that we
    can let network unavailablity stop all work. Having two loosely-
    coupled systems works to our advantage in many environments.

    With RSA's SDI4Win infrastructure, PC users temporarily disconnected
    from the network can still use their SecurIDs for local access, and
    laptop users remain free to roam. A corporate laptop user can use his
    SecurID (and memorized PIN) to access his mobile machine in a plane at
    35,000 feet, even without a network connection, because the RSA
    Authentication Manager (what RSA used to call the ACE/Server) stores a
    secure cache of future SecurID token-codes -- for a variable number of
    days (pre-set, per user or group, by the network admin) -- on the
    laptop.

    When the PC or laptop again connects with the enterprise network and
    the RSA Authentication Manager, the laptop's Authentication Agent
    forwards an audit log to the RSA Authentication Manager about what has
    happened in the interim... and replenishes its stored cache of SecurID
    token-codes for future off-line access.

    With the new IT security requirements associated with various external
    regulatory regimes (Basel II, Sarbanes-Oxley, HIPAA, GLBA, etc.), many
    enterprises find it necessary to have audit records and strong access
    controls on all repositories of proprietary or confidential corporate
    data. As necessary, these AAA systems can be buttressed by crypto,
    SSO, and federated access controls, but the operational baseline for
    strong authentication is no longer limited by network access, nor
    limited to perimeter access controls.

    This is new, but since RSA is providing this capability at no
    additional charge to all of the thousands of sites which use the
    current version of the ACE/Server (aka, the RSA Authentication
    Manager), it will probably be widely adopted fairly quickly.

    Back to biometrics:

    Perhaps the most successful use of biometrics I have seen is the use
    of a local biometrics check to block fraudulent multiple claims in
    benefits payments in the social services. In that mode, the benefits
    recipient is first registered on a secure terminal, under supervision.
    A central record is made of the recipient's ID and biometric (a
    fingerprint, as I recall) and his approved benefits, and a check is
    made to make sure that recipient is making no other claims on the
    system under another identity.

    To pick up his benefits payment, the recipient shows up at an office
    where he goes through a quick process which merely matches his
    biometric to the card he carries. My recollection is that such a
    system -- in use in several states including Connecticut -- cut
    benefits fraud very effectively and paid for itself very quickly.

    A targeted function; a problem resolved.

    Suerte,

    _Vin

    PS. Hi Rob!
     
    Vin McLellan, Oct 7, 2004
    #10
  11. (Vin McLellan) writes:

    >Bruce Barnett <> wrote:


    >>>>This also requires the reader to be connected to the server in
    >>>>order to be authenticated. If the network is down, or disconnected,
    >>>>the person cannot be authenticated. So that's two potential
    >>>>problems.


    >Richard S. Westmoreland <> replied:


    >>>Server or desktop/laptop - can be connected to either. If I have
    >>>an RSA SecureID, and the server is down, I'm not getting on then
    >>>either. I thought the point was authentication to the *network*?
    >>>No network, then I sit and wait until it's fixed.


    >Actually, at least so far as RSA's SecurID, this is no longer true.


    >Working with Microsoft, RSA developed a new SecurID for Windows
    >(SID4Win) infrastructure that not only simplifies the user experience


    %@#$!! "simplifies the user experience"?

    Sounds like it's more concerned with marketing drivel than security.

    Please try not to spam newsgroups with press releases.

    [snip]
    --
    /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
    \ / ASCII ribbon campaign | I'm a .signature virus!
    X against HTML mail | Copy me into your ~/.signature
    / \ and postings | to help me spread!
     
    Bernd Felsche, Oct 7, 2004
    #11
  12. Rob Slade, doting grandpa of Ryan and Trevor

    Vin McLellan Guest

    In a thoughtful discussion of multi-factor authentication options,
    Bruce Barnett <> wrote:

    ..> This also requires the reader to be connected to the server
    ..> in order to be authenticated. If the network is down, or
    ..> disconnected, the person cannot be authenticated.

    Rick Westmoreland <>, worried about the lack
    of strong authentication on the desktop or mobile laptop, and the
    traditional dependence of any strong authentication mechanism on
    a network connection, replied:

    /> Server or desktop/laptop - can be connected to either. If I
    /> have an RSA SecureID, and the server is down, I'm not getting
    /> on then either. I thought the point was authentication to the
    /> *network*? No network, then I sit and wait until it's fixed.

    Vin McLellan (me) interjected:

    >> Actually, at least so far as RSA's SecurID, this is no longer
    >> true.


    >> Working with Microsoft, RSA developed a new SecurID for Windows
    >> (SID4Win) infrastructure that not only simplifies the user
    >> experience by replacing the traditional Window's logon password
    >> with a SecurID, it requires (and keeps an audit record of)
    >> two-factor authentication not only at the network perimeter, as
    >> is traditional, but also wherever corporate data is stored.

    <snip>

    Bernd Felsche <> jumped in like a
    self-righteous moderator:

    > %@#$!! "simplifies the user experience"?
    >
    > Sounds like it's more concerned with marketing drivel than
    > security.


    I apologize if what I wrote was not clear enough to let you
    recognize that the simplification in the user experience I
    describe is concrete, a matter of time and process, quantity as
    well as quality. I trust that others more familiar with
    multi-factor authentication on Windows, one-time password (OTP)
    technologies, or the Windows security architecture understood me
    better.

    Typically, today, strong OTP authentication options like RSA's
    two-factor SecurID are added to the Windows logon as a secondary
    layer of authentication. That is, the user is first challenged for
    his username and Windows password. Then, after that password is
    validated by the OS, the user is challenged again for his username,
    his memorized PIN, and the 60-second token-code that is displayed
    on his SecurID token.

    Microsoft and RSA have changed this. RSA's SecurID -- like
    smartcards -- is now a native authentication option for Windows.
    The user will only be challenged once, for his username and SecurID
    passcode.

    In the eyes of millions of current SecurID users, this will indeed
    offer a welcome simplification in their logon experience.

    I went on to describe RSA's new SID4Win architecture because it
    directly informed the discussion Bruce and Rick were having
    about strong multi-factor authentication. Their comments about the
    potential of OTPs and, specifically, about RSA's SecurID -- a
    widely-used commercial product they mentioned by name -- were dated
    and now inaccurate.

    Given the tenor of their discussion, I was certain they would
    appreciate new factual information.

    I offered them a quick summary of the latest enhancements
    available for OTPs on Windows, since I recognized that the new
    AAA options available with RSA's SID4Win were precisely on-topic
    and could usefully inform this discussion.

    This new technology. Only someone recently released from
    an NDA by RSA is likely to be able to offer the newsgroup
    accurate information about this technology and the context in
    which it was developed. (And their aren't many people with those
    qualifications who post to the newsgroups;-)

    So I offered relevant OT information:

    1. The baseline for strong multi-factor authentication on Windows
    has changed. Windows now has a native OTP option for logon.

    2. Audited OTP access controls on the Windows domain controller
    is now available.

    3. Local OTP authentication mechanisms to restrict access to
    corporate XP desktops, and/or mobile corporate laptops, are now
    commercially available.

    4. Strong multi-factor OTP authentication on PCs is no longer
    constrained by the need for an omnipresent network connection.

    This is not PR wind. These are, I believe, useful facts which
    contribute meaningfully to this thread.

    I do apologize for the truncated second post (I cancelled it). I
    also apologize for not mentioning that I have been a consultant to
    RSA for most of the past 15 years. My newsreader was going a little
    crazy and trying to fire off incomplete messages on its own. Like
    most old-timers on the Net, I am habitually religious about
    mentioning my affiliations when I discuss any vendor's technology.
    Mea culpa.

    Suerte,
    _Vin


    Vin McLellan ** The Privacy Guild ** Chelsea, MA USA
     
    Vin McLellan, Oct 7, 2004
    #12
  13. Rob Slade, doting grandpa of Ryan and Trevor

    Vin McLellan Guest

    In a thoughtful discussion of multi-factor authentication options,
    Bruce Barnett <> wrote:

    ..> This also requires the reader to be connected to the server
    ..> in order to be authenticated. If the network is down, or
    ..> disconnected, the person cannot be authenticated.

    Rick Westmoreland <>, worried about the lack
    of strong authentication on the desktop or mobile laptop, and the
    traditional dependence of any strong authentication mechanism on
    a network connection, replied:

    /> Server or desktop/laptop - can be connected to either. If I
    /> have an RSA SecureID, and the server is down, I'm not getting
    /> on then either. I thought the point was authentication to the
    /> *network*? No network, then I sit and wait until it's fixed.

    Vin McLellan (me) interjected:

    >> Actually, at least so far as RSA's SecurID, this is no longer
    >> true.


    >> Working with Microsoft, RSA developed a new SecurID for Windows
    >> (SID4Win) infrastructure that not only simplifies the user
    >> experience by replacing the traditional Window's logon password
    >> with a SecurID, it requires (and keeps an audit record of)
    >> two-factor authentication not only at the network perimeter, as
    >> is traditional, but also wherever corporate data is stored.

    <snip>

    Bernd Felsche <> jumped in like a
    self-righteous moderator:

    > %@#$!! "simplifies the user experience"?
    >
    > Sounds like it's more concerned with marketing drivel than
    > security.


    I apologize if what I wrote was not clear enough to let you
    recognize that the simplification in the user experience I
    describe is concrete, a matter of time and process, quantity as
    well as quality. I trust that others more familiar with
    multi-factor authentication on Windows, one-time password (OTP)
    technologies, or the Windows security architecture understood me
    better.

    Typically, today, strong OTP authentication options like RSA's
    two-factor SecurID are added to the Windows logon as a secondary
    layer of authentication. That is, the user is first challenged for
    his username and Windows password. Then, after that password is
    validated by the OS, the user is challenged again for his username,
    his memorized PIN, and the 60-second token-code that is displayed
    on his SecurID token.

    Microsoft and RSA have changed this. RSA's SecurID -- like
    smartcards -- is now a native authentication option for Windows.
    The user will only be challenged once, for his username and SecurID
    passcode.

    In the eyes of millions of current SecurID users, this will indeed
    offer a welcome simplification in their logon experience.

    I went on to describe RSA's new SID4Win architecture because it
    directly informed the discussion Bruce and Rick were having
    about strong multi-factor authentication. Their comments about the
    potential of OTPs and, specifically, about RSA's SecurID -- a
    widely-used commercial product they mentioned by name -- were dated
    and now inaccurate.

    Given the tenor of their discussion, I was certain they would
    appreciate new factual information.

    I offered them a quick summary of the latest enhancements
    available for OTPs on Windows, since I recognized that the new
    AAA options available with RSA's SID4Win were precisely on-topic
    and could usefully inform this discussion.

    This new technology. Only someone recently released from
    an NDA by RSA is likely to be able to offer the newsgroup
    accurate information about this technology and the context in
    which it was developed. (And their aren't many people with those
    qualifications who post to the newsgroups;-)

    So I offered relevant OT information:

    1. The baseline for strong multi-factor authentication on Windows
    has changed. Windows now has a native OTP option for logon.

    2. Audited OTP access controls on the Windows domain controller
    is now available.

    3. Local OTP authentication mechanisms to restrict access to
    corporate XP desktops, and/or mobile corporate laptops, are now
    commercially available.

    4. Strong multi-factor OTP authentication on PCs is no longer
    constrained by the need for an omnipresent network connection.

    This is not PR wind. These are, I believe, useful facts which
    contribute meaningfully to this thread.

    I do apologize for the truncated second post (I cancelled it). I
    also apologize for not mentioning that I have been a consultant to
    RSA for most of the past 15 years. My newsreader was going a little
    crazy. It was (and still is) trying to fire off incomplete messages
    on its own. Like most old-timers on the Net, I am habitually
    religious about mentioning my relevant affiliations when I discuss
    any vendor's technology. Mea culpa.

    Suerte,
    _Vin


    Vin McLellan ** The Privacy Guild ** Chelsea, MA USA
     
    Vin McLellan, Oct 7, 2004
    #13
  14. (Vin McLellan) writes:

    > Microsoft and RSA have changed this. RSA's SecurID -- like
    > smartcards -- is now a native authentication option for Windows.
    > The user will only be challenged once, for his username and SecurID
    > passcode.


    I was playing with musclecard and PAM today, and by changing one line
    you can select one of the following combinations

    Password + PIN are both required
    If token and reader available, use PIN, else use password
    Use password only
    Use Token/PIN only

    Another line will allow/deny root's ability to log in without a token

    > In the eyes of millions of current SecurID users, this will indeed
    > offer a welcome simplification in their logon experience.


    Yup. Sounds good.

    --
    Sending unsolicited commercial e-mail to this account incurs a fee of
    $500 per message, and acknowledges the legality of this contract.
     
    Bruce Barnett, Oct 8, 2004
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. m1k30rz

    Paul Zimmerman

    m1k30rz, Jun 21, 2005, in forum: Case Modding
    Replies:
    25
    Views:
    5,627
    unholy
    Aug 14, 2005
  2. Boomer

    reid decker WHEN...

    Boomer, Jun 16, 2004, in forum: Computer Support
    Replies:
    12
    Views:
    744
    reid decker
    Jun 16, 2004
  3. Boomer

    reid decker Please

    Boomer, Jun 16, 2004, in forum: Computer Support
    Replies:
    2
    Views:
    472
    Boomer
    Jun 16, 2004
  4. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "The Secured Enterprise", Paul E. Proctor/F. Christian Byrnes

    Rob Slade, doting grandpa of Ryan and Trevor, Sep 1, 2004, in forum: Computer Security
    Replies:
    0
    Views:
    457
    Rob Slade, doting grandpa of Ryan and Trevor
    Sep 1, 2004
  5. kalvin5
    Replies:
    0
    Views:
    1,035
    kalvin5
    Nov 8, 2012
Loading...

Share This Page