I read that CER has to send multiple vendor specific application ids to advertise all the applications that the diameter node supports.
If that is true then what is the application id value in the diameter header.
Also I dont understand when when the following three are to be used-
Acct Application id AVP, vendor specific application id AVP and Auth Application id
ApplicationId in the header is always there no matter which Diameter request you are sending.
Therefor its there also in CER (see RFC 3588 section 3)
In the CER:
You should use Acct-Application-Id AVP in packet of type Accounting (see RFC 3588 section 6.9)
You should use Auth-Application-Id AVP in Authentication and Authorization type packet (see RFC 3588 section 6.8)
Vendor-Specific-Application-Id AVP is used to support of a vendor specific Diameter Application and in order to describe it you must add to it Acct-Application-Id AVP or Auth-Application-Id AVP (see RFC 3588 section 6.11)
Related
I am working on a project which requires Secure Messaging of an EMV card to protect data sent to/received from EMV cards.
According to the EMV Book 3, section 6.3.2:
For my understanding, we can use 'Secure Messaging' on every command/response pair.
For example, we can use CLA='8C', INS='CA' for Secure Messaging Format 1, and CLA='84', INS='CA' for Secure Messaging Format 2
However, when I tried on two of my cards I got error 6E 00 -- Class not supported.
What's wrong with my understanding about the 'Secure Messaging'?
None of the current EMV protocols seem to support secure messaging. Consequently, your card/EMV applet won't support secure messaging either.
Also, I'm not quite sure what exactly you would want to use secure messaging for ... Excahnged information is already authenticated (under the assumption that you perform a transaction and that you do CDA/SDA/DDA). So you probably aim for encrypting the information exchanged between the terminal and the card (specifically things like the amount charged, static card data, etc.) However, I doubt that this would make much sense based on the design of the current EMV infrastructure:
Terminals are currently not assumed to be trusted (at least with regard to the EMV protocol exchange between the terminal and the card). Consequently, you won't be able to implement any form of mutual authentication between the terminal and the card. Only the terminal could authenticate the card, the card could authenticate information received from the issuer (e.g. issuer scripts), but the card could never authenticate the terminal. As a result, impersonation of the terminal side would be possible despite encryption. Hence, an attacker in the middle would still be able to read and decrypt messages.
From a comment by Michal Gluchowski:
Maybe to extend what Michael has said, where next generation EMV is planning to go is to introduce channel confidentiality to eliminate passive eavesdropping. It will, however be possible to impersonate terminals (only card certificates will be authenticated). Current EMV uses secure messaging only for issuer scripts as it requires symmetric secret key that is known to issuer only. From the transaction perspective all the data terminal exchanges are plaintext (and issuer scripts are simply passed through without terminal analyzing or modifying them).
Source regarding next generation EMV & channel security: Next Generation Kernel System Architecture Overview, EMV 2nd Generation, Version 1.0, Sept. 2014
The abstract for RFC 4211 seems to say that the RFC is meant to be a spec for CRMF (which I understand to be a protocol for transmitting a CSR), while RFC 2986 specs out the CertificationRequest information type, which seems also be a CSR.
What is CRMF, how does it relate to a CSR, and which RFC ultimately specs out a CSR?
Thanks!
CRMF is one way to request a certificate SCEP is another, and so is ACME.
The Rfc 2986 specifies PKCS#10, which is what a CSR is. Most protocols transmit PKCS#10 plus some more info (for instance authentication ands other metadata).
I have asp.net web api used by mobile app. In facebook I see notifications like "access to your account from new device". I want to implement the same. Device could be connected to different wi-fi or 3G so to use ip addrress is not good. How to define access from new device and remember it for future in "trusted devices"?
You could look at a combination of pieces of data to uniquely identify see EFF's website on browser fingerprinting.
But the common approach is to set a cookie and check if it is present in future visits.
You need a unique identifier for each device.
In case of a computer it could be a mac address, if it's a mobile device they each have a unique identifier you could send together with the request.
You would then keep a list of these IDs on the API side and every time a request comes in, just check if that ID is in the list you already have. If not then there it is .. new device.
Here is another discussion which could be relevant to your scenario : What is a good unique PC identifier?
I would like to use the paypal API to perform a payment from server side.
looking at their API https://developer.paypal.com/docs/rest/api/payments/#payment.create I willneed to send the credit card number. However this is not PCI compliant,
How can I protect the PAN when I pass it to paypal?
If you would like to process direct cards on your website, you will need to be PCI compliant.Look at this link.
Per the PCI DSS 3.1, requirement 4 details what strong cryptography and protocols should be used. Additionally, within requirement 4.1,
Sensitive information must be encrypted during
transmission over public networks, because it is
easy and common for a malicious individual to
intercept and/or divert data while in transit.
Therefore, since all SSL and TLS 1.0 implementation are not considered secure, I would suggest encrypting the data via TLS 1.2 when it goes over the intenet by accessing the REST interface via HTTPS and ensuring that TLS 1.2 is used.
I'm a little confused about Basic authentication in regards to web browsers. I had thought that the web browser would only send an Authorization header after having received an HTTP 401 status in the previous response. However, it appears that Chrome sends the Authorization header with every request thereafter. It has the data that I entered once upon a time in response to a 401 from my website and sends it with every message (according to the developer tools that ship with Chrome and my webserver). Is that expected behavior? Is there some header I should use with my 401 to infer that the Authorization stuff should not be cached? I'm using WWW-Authenticate header currently.
This is the expected behavior of the browser as defined in RFC 2617 (Section 2):
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Similarly, when a client sends a request to a proxy, it may reuse a
userid and password in the Proxy-Authorization header field without
receiving another challenge from the proxy server. See section 4 for
security considerations associated with Basic authentication.
to my knowledge, Basic HTTP authentication has no ability to perform a logout / re-authentication. This along with the lack of security of HTTP Basic authentication is why most websites now use forms and cookies for auth solutions.
From RFC 2617:
If a prior request has been authorized, the
same credentials MAY be reused for all other requests within that
protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference.
From my experience it is quite common to see browsers automatically sending the Basic credentials for subsequent requests. It prevents having to do an extra round trip for additional resources.